trueanomaly

[trueanomaly]

Object Orientation: How Much is Too Much?

Has object orientation gone too far? Has the effort to build infinite reusability taken a turn for the absurd?

Maybe. Maybe not. Let’s have a look.

In theory, object orientation seeks to build code the way we build physical devices: it makes more sense to build general, modular, reusable components rather than specific, intertwined, inseparable ones. Take your car engine for example. The starter motor, alternator and battery can all be swapped out individually without changing the engine. Any replacements will drop right in, provided they have right interfaces, in this case, the voltage (12V), the starter gear meshes with the ring gear on the flywheel and has the proper bolt pattern to mount to the engine block, the alternator spins at the right RPM on the serpentine belt, etc. This is possible because the starter, alternator and battery are dumb, they don’t know what engine they’re on, they just do their job (although the bolt patterns mentioned may limit their use to a specific engine block).

This analogy defines objects, composition, and interfaces. It’s not hard to extend it to include inheritance: if we want to build a 24V starter motor, we can probably reuse some of the parts from the 12V version. Nor are the concepts of public and private properties difficult: the battery terminals are publically accessible, the cells inside the battery are private. The alternator rpm is a public method (we can spin it as fast as we want).

In theory, all together these OO features allow the programmer to build code that is safe (avoids bugs created by plugging incompatible objects together), allows changes to be made in one spot only and propagate everywhere by default (no duplicated code), and reusable (no reinventing solutions).

These OO concepts come directly from the physical world. Others aren’t so easy to find a physical analogue: static methods, abstract interfaces. A static method is like taking an Uber, it gets you where you want to go without buying a car. An abstract interface is like a standard that everyone chooses to follow so that things work together, the electrical sockets on the wall have a common plug for example. Outlets in other countries that implement different voltages use a different plug type to avoid damage, i.e. type hinting.

Like any theory, practice is imperfect. People who subscribe to theory regardless of this fact are ideologues, which doesn’t make them evil, but it’s always worth questioning if strict adherence to theory is doing more harm than good. Case in point: the React framework for JS broke the almost religious devotion programmers had to an architecture known as MVC.

MVC required the definition and instantion of a model (with all its properties and methods) anytime a view needed to reflect some user supplied data (because models and views were bound through events) even if that data never needed the local storage or send to server methods, etc. One only had to build a single complex UI to see the ridiculous amount of code that required the programmer write to say, “hmm...is this really the best way to do this?” (This post is not a defense of React, you can do your own research there, now back to the original point.)

If time tested theories like MVC can, in fact, be rethought, what about OO? While it would certainly be difficult to defend spaghetti code, there are occasions when abstraction goes too far. The factory pattern teaches that it is best to send our request to a “factory” (or agent, or broker) that produces the appropriate variant that we need to get the job done, like a travel agent picks the best flight for us. For example, instead of having our models build themselves from database data, have a “mapper” object get the data and pick the right model to build. That way, in the future, should we decide to change the database, we only change the code in one place, not on every model.

It’s easy to see how this pattern of abstraction can turn our code into a fractal, putting agents in front of agents in front of agents...when are we going to write the code that actually does something!?

This point has been made by many before. The zealous devotion to putting everything into classes, using static methods to get around the awkwardness of this, leads to the creation of many, many unnecessary lines of code, and potentially hours of lost productivity worrying about how best to abstract your functionality to plan for future use rather than simply writing the functionality now.

The fundamental question, like it was when React challenges MVC, is: when has a devotion to a structure become a hinderance rather than an aid? Functions can be written in a way that avoids code duplication and provides for reuse without the complexity of building classes and instantiating objects.

It is my opinion that JavaScript has thrived because of its classless nature, and the ever steady march toward molding JS into its ancient ancestors is a fools’ errand.

What do you think? Tweet me.

[trueanomaly]

On TypeScript, JavaScript and the Future of Programming

Let me preface this by saying I do not consider this to be the only valid opinion on this subject, but I feel I have to offer it, because I see so little out there from this viewpoint. Granted, if everyone disagrees with me, perhaps I am, in fact, wrong. And if I am, so be it, but here goes anyway:

No one can predict the future of programming, but one thing seems virtually certain: JavaScript, in some form or another, will endure. JS has a proven track record of evolving to be whatever necessary to grow and spread. In the unfortunate event on a nuclear apocalypse, the cockroaches may take over the Earth by learning JS. Well they’ll probably take over anyway...but...learning JS couldn’t hurt...:)

If you’re like me, you learned JS during a time when it changed drastically from a language that put goofy animations on static web pages to a fully featured object oriented language that powers apps and servers alike. For the last decade, learning JS has seemed like running a marathon- there’s never time for a break before the language changes drastically again-and we’re not just talking about feature additions like promises, for example, we’re talking about massive syntax overhauls and language subsets like coffeescript that are completely unreadable to those who only know vanilla JS. ES 2016 added essential functionality for JS to be the de facto standard app language. Now, the debate over the widespread adoption of TypeScript rages, with an ever increasing number of proponents claiming it as the future of the language.

But not me. I believe that TypeScript is a step backwards for JavaScript. The very reasons that made JS into what it is today are destroyed by strong typing. Let me show you why:

1. JS is easy to learn. If you have to learn strict typing you might as well learn Java.

2. JS makes prototyping ideas fast. Not so with TypeScript, which makes even the simplest idea into an enterprise level production.

3. JS is easy to read, at least compared to strongly typed languages, which require even simple statements to be prefaced by data types, adding to the appearance of complexity, even if the code is functionally the same. Just read a line to see what I’m talking about.

4. Loose typing is awesome. Automatic variable conversions are great, so long as you can handle freedom.

There are probably more reasons to love JS, these are just a few. But the future will belong to the language that attracts the most developers going forward, and the next round of developers are not computer science majors. As more things become code, more programmers are necessary, meaning that programming cannot be reserved for the extremely intelligent, it must be accessible to all, much like any trade. In fact, there are a growing number of people looking into and building visual code builders, but I believe there will always be a need for coders, and a need for a fast, easy to read, easy to learn, easy to use language.

JS must continue to be the language of the future. Yes, this involves adding capability when needed, but adding capability does not, and should not require JS to be a language it is not, nor ever has been. Vanilla is a delicious flavor, and there’s nothing wrong with vanilla JS.

Let me know your thoughts! Tweet me!

[trueanomaly]

4 Total Noob Mistakes in JavaScript

Hopefully this post won’t help your code at all, but maybe you’ll reminisce about the good ‘old days! Before you get offended, realize we all searched these on Stack Overflow at one point. Or, at least, we’ve heard that some people have.

1. Binding handlers to DOM events of things not yet in the DOM.

(Fortunately, frameworks like React make this much harder)

2. Forgetting to unbind event handlers when the UI changes, then binding them again when it changes back, leading to memory leaks and eventually a total crash.

(Even a framework won’t stop this, you still have to fill in your component unmount!)

3. Putting code dependent on a callback or promise return outside of the callback or promise resolution block.

(Ive never done this, but I’ve heard of some people who have ;)

4. Spelling JavaScript with a lowercase “s”.

(Ok, this one is controversial... I’m not sure I’m a fan on the camel case)

What are your top, total noob JavaScript mistakes? Tweet me.

[trueanomaly]

What the heck am I supposed to learn? How to pick a path to learn app development

I know. It’s overwhelming. Just look at all the obscure names and acronyms: Python, PHP, JavaScript, Java, Swift, Objective-C, C++, Angular.js, and on and on! You want to learn app development, but where do you even start!?

Worse yet, so much seems to be duplicated: Swift is for iOS apps but so is Objectjve-C? Java is for Android but so is Kotlin? JavaScript is everywhere but Python is all the rage? When you learn that Angular.js is a framework for JavaScript apps, but so is React.js, and so is Vue.js and so is... and just when you think you found a pattern (I get it! All the names that end in .js are JavaScript UI frameworks...) you discover an exception (Node.js, a Javascript server)! Ahhhh!

Let me do what I can to sort out some of this mess. First, some definitions.

There are programming languages (that write the instructions that power the app), frameworks (many many lines of premade code that make it substantially easier to build an app) and libraries (groups of functions that do common tasks).

Frameworks are written in a language and provide a solution to a common programming task, such as building a User Interface (UI). This is so common that there are many UI frameworks out there, remember that you don’t need to learn more than one. In the end, they all do the same thing in different ways. At all times, remember that there are many ways of doing something and that programmers love to iterate on others’ work to make it simpler, solve more complex problems than it was originally designed to, just for the fun of it. If you follow one of the many JavaScript channels on Twitter you will see a constant stream of new stuff released and may feel overwhelmed. Do you need to learn all of it? The short answer: no.

Also, a good framework can sometimes replace a library. React and Angular JavaScript frameworks have made the old staple library jQuery nearly obsolete, and you only have to learn React or Angular, not both. Also, the names can be displayed different ways, all meaning the same thing. React, React.js, and ReactJS all refer to the same framework for example.

Why are there so many languages, and why do they change? Languages are built to solve specific problems, and sometimes those problems become really popular, making the language very popular. A big following can lead to a language adopting new features (as developers invent new engines to interpret it) thus exposing new features. A language is only as powerful as it’s environment, that is, the context under which the code is executed. This environment differs depending on what we are programming: it could be a microcontroller, an operating system, or an operating system and a web browser or an operating system and some other runtime environment.

Lower level compiled languages like the C family of languages generally have the most capability as they give the programmer access to memory on the bit level, and do not require an operating system as an environment. Thus they can program electronics and microcontrollers as well as PCs. On the hand, this power makes these languages difficult to learn and leads to even simple apps requiring lots of boilerplate (repeated code). Thus programmers wrote thousands of languages on top of these lower level languages that get interpreted on the fly. Interpreted languages are generally easier to learn although are often tailored to specific tasks.

Programming languages fall into and out of favor. Stack Overflow, a programmer help website tracks the usage of languages based on the number of questions posted on their site. Currently, Python is king due to new applications of the language in the AI and IoT fields, not to mention it’s one of its original applications for web servers. PHP on the other hand, once the darling of the web, the language that built Facebook and so many other database driven apps, is on its way out due to a lack of support for real time web apps and the advent of Node, which allows a server to be programmed in the same language as websites (JavaScript).

Eventually, even the best languages get rewritten as their applications change. Sometimes this happens as an adaptation of the language, in which case the name is kept but a version number added, as in PHP 5 for example. Other times, a language is reworked to the point it is not recognizable and given a new name. Swift, which remains interoperable with its predecessor, Objective-C, makes it much easier to build iOS apps by fixing difficulties with the old language. Essentially all new iOS apps will use Swift. Android did something similar when they switched to Kotlin over Java.

If you want to learn one biased-but very potent-path forward for app development in multiple environments, check out my book, Learning to Build Apps https://www.amazon.com/Learning-Build-Apps-Nathaniel-McMahon/dp/1732928800/ or follow my blog for more tips!

[trueanomaly]

Build React the Old School Way

The React website (https://reactjs.org/docs/add-react-to-a-website.html) lists a couple of ways to add React to a web app that differ from the manual shell script specified in Stoyan Stefanov’s book (https://amzn.to/2YIJD27), which is the book I used to learn React a while ago. Unfortunately, updates to React and Babel prevent the original shell script in that book from working.

I still think it’s worth knowing what’s going on in the compile / bundle process rather than having it all hidden away with the two methods on the React website, so let me show you a way to update the script so that it works with React apps today.

Create the following shell script called build.sh (or whatever you want). Also, change the css bundling to fit your particular director structure, and the name of the js app file to whatever you use. The echo date line is just to see the finished time in the terminal. 

And add the dependencies to your package.json.

Now run npm install to get everything installed, but remember this installs things locally in your project folder, not globally, so Babel and Browserify won’t run on the command line (as your project folder isn’t in your $PATH variable). So add your build shell script to the the “scripts” section of package.json.

Then, to run it, navigate to your project folder in your Terminal and type npm run build. This will run the shell script and find the executables in the appropriate places in your node_modules folder. Old school build method!

Hope this helps! Follow my blog for more tips and insights!

Disclosure of material connections: Some of the links in the post above are “affiliate links”. This means if you click on the link and purchase the item, I will receive an affiliate commission. Regardless, I only recommend products or service I use personally and believe will help you out! I am disclosing this to comply with Federal Trade Commission 16 CFR 255. 

Some of the products or services mentioned here may be claimed as trademarks. All trademarks are the property of their respective owners.

[trueanomaly]

But the title of this blog! How dare you!?

Wait, which valley!? Surely you don’t mean that valley! Yes I do. Silicon Valley, The only valley that matters. Once, a long time ago, a man asked my father-a Vietnam veteran and Purple Heart recipient-if he were in combat in the Ia Drang Valley of Vietnam. My father, who was in country in 1969 (years after the ferocious fighting in the Ia Drang), responded, “No.” The man looked disappointed. My father continued, “I may not have been in the Ia Drang Valley, but I was in a lot of other sh***y valleys!” 

Now what does that story have to do with this blog? Nothing. So how then, can I make the ridiculous proclamation that I am twelve steps ahead of SV!? I do know that twelve historically represents completeness, so to say you are twelve steps ahead is like saying you are completely ahead of Silicon Valley! And I’m in Detroit! Blasphemy! It’s true. Detroit is not technologically ahead of SV. But ideas don’t come from sand (get it, sand, silicon... ok nm). Now you might say ideas don’t come from rust either, and that’s fair, but a lot of businesses in the middle west are still ripe for disruption, and to see the opportunity it helps to be amongst it. (Some argue the opposite: you can’t see the forest for the trees, so you ought to be outside it to see the opportunity, but if you follow this blog, you will eventually come to know Detroit-and the midwest itself-has fractal like complexity that only an insider can understand).

This blog is basically me hurling out multi-million dollar business ideas based on my experience here in Detroit and the middle west. My hope is that other midwest based entrepreneurs will read them, steal them, and leave me in the dust, poor, broken, and alone. Or cut me a check. Whichever works.

If you find any of this even remotely interesting, follow me, or check out my website https://trueanomaly.com.

Okay, now you know what to expect. Now follow me and live your wildest dreams! :).