The eli4d Gazette – Issue 051: JavaScript Array/Object Methods and the Meaning of “=”

An Excellent Syntax.fm Episode on Array and Object Methods in JavaScript

The Syntax.fm podcast had an excellent episode covering Array/Object methods, as well as shallow versus deep copies and reference versus copies in JavaScript. It is an episode that I’m highly recommending to my JavaScript students.

What does “=” mean?

Another programming topic – assignment versus equality. Hillel Wayne covers this concept/issue in an excellent article about this very issue. If you’re new to programming, here are some pointers to the terminology used in this article:

Image credit: This nice high-resolution image comes from the DigiBarn museum site.

Mother Tongues


Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 047: Keeping up with Software Industry and Developer Marketing

Keeping up with the Fast Pace of the Software Development Industry

The Syntax.fm podcast had an excellent episode about the issues (and solutions) of keeping up with the fast pace of software development. While this podcast is more skewed towards JavaScript, the suggested approaches apply to all programming languages, libraries, and technologies. Some interesting points (which I bookmarked in my twitter feed):

  • At 15 minutes and 46 seconds: a sane approach to this fast-moving field
    • maintain core programming skills in whatever language that you’re versed in
    • practice “just in time learning” for everything else
  • At 47 minutes and 42 seconds: how to stay up-to-date

Developer Marketing and Landing Pages

I listened to 2 excellent episodes from the Release Notes podcast about the art of creating landing pages for various types of products. Justin Jackson does an excellent job of explaining his approach, as well as providing actionable advice. You can find the episodes here:


Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 046: Programming Language Affordance and DHH’s Reason for StimulusJS Creation

Tech Pick (Programming Language Affordance)

I am a huge fan of Sandi Metz. She’s like one of those Zen masters that snap their students out of their current perceptual ruts.

In a recent article (‘What Does OO Afford’) Sandi goes into a great reflection about Object Oriented programming and the affordances that this approach provides. It’s a great and worthwhile post. One section that strikes me is the following:

Just like varying styles of doorknob, different programming languages offer their own unique affordances. Language designers have preconceived ideas about the best way to model reality, and their creations reflect these biases. Thus, programming languages are explicitly designed to “enable” certain kinds of thinking.

I’m talking about something that’s deeper than syntax. Languages have points-of-view: they’re designed to be used in certain stylized ways. The mere fact that code compiles doesn’t mean it’s arranged as the language designer intended.

While it’s possible to warp most any programming language into use by an alternate way of thinking, working at cross-purposes from your language’s intentions is not the most efficient way to write code. Don’t roll this rock uphill. If you don’t understand your language’s affordances, learn them. If your coding inclinations conflict with the designer’s biases, yield.

The above puts language wars in perspective. A language is designed to model reality in a certain way. If it takes off due to significant adoption (whether organic or through environment limitations like JavaScript), then warping occurs as developers try to use this hammer to nail every problem.

Media Pick (JavaScript Framework Choice)

The most recent Full Stack Radio podcast fits quite well with Sandi’s article. It features an interview with David Heinemeier Hansson.

In this interview, he discusses his company’s (Basecamp) release of a JavaScript framework named Stimulus. It’s interesting to learn how he chose Ruby‘s affordances over the those given by various JavaScript frameworks (like React, Vue, etc…). So Stimulus supports this choice by keeping as much of the programming on the server side via Ruby and Ruby on Rails.


Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 045

Tech Pick (JavaScript)

I watched a short (15 minutes) presentation by Rebecca Hill that covered JavaScript debugging. It’s an excellent talk and demonstration of available tools beyond console.log. If you do any sort of JavaScript development (whether frontend or backend), this is well worth watching. Some topics she covers:

  • using the console’s capabilities beyond console.log

  • approaches for proxying services when dealing with something that’s out of your control

  • Usage of VS Code (this was really really good) regarding:

    • frontend debugging
    • Node.js debugging

Media Pick (GTD Podcast)

I have found that Getting Things Done is a pretty good approach to task/project management both at home and at work.

The most recent episode of GTD Podcasts was a good one. In this episode David Allen covers the power of outcome thinking and the brain mechanism (reticular formation) in getting you from your present circumstance to the successful completion of a project (whatever it may be).


Thoughts? Feedback? Let me know: @eli4d on Twitter


The eli4d Gazette – Issue 019


Issue 019: 2016-11-23

Media Pick

This comes by way of Studio Neat’s newsletter. It’s a video that explores the amazing acting ability of Anthony Hopkins through a dissection of a scene in HBO’s Westworld. You can find this video here: https://m.youtube.com/watch?feature=youtu.be&v=4kSGkGKwp9U

Tech Pick

I’ve been noticing many ReactJS articles come across my various readings. While I have not had the opportunity to explore React (yet) I find React and these React-related articles quite interesting:

  • Dave Ceddia’s How To Learn React (and what to build along the way) and Your Timeline for Learning React articles are quite good in that:
    • The emphasis is on starting from fundamentals (i.e. JavaScript is step 0) and then focusing on getting going on React without the confusing overhead of associated technologies (i.e. Redux, Webpack, etc…).
    • The focus is on building small blocks that teach you about React.
    • Note: Dave is selling a book that covers React in the above ways. It’s on my list of things to buy/learn, so I will review it after I do that. The long and short of all of this is that his approach (as described by his articles) is a solid one for beginners, so my hope is that his book is solid in the same way.
  • A Study Plan to Cure JavaScript Fatigue: This article was created by the same developer that created the JavaScript survey (which I mentioned in issue 018). It is a good article to see where you can go with React, rather than an actual plan fo study React. In fact, the title itself states this because it’s a response to a JavaScript fatigue article. From a React learning point of view:
    • He has great images that show the evolution of JavaScript Apps (and web applications in general). I think that this is the great value of this article.

    • He glosses a bit about learning JavaScript indicating that you should only “know basic JavaScript syntax.” I disagree with this notion because JavaScript’s design is quite different from typical OO based languages (i.e. the functional aspects like functions being first class values, etc…). So sure – you should know syntax, but you also need to know how JavaScript ‘thinks’ due to its design. (Disclaimer: I do teach a JavaScript based beginner programming course but I would still state this even if I didn’t teach such a course)

    • “Bonus Week 5” jumps to GraphQL and bypasses REST altogether. GraphQL is still early days for most projects and for better or worse REST is a current standard. I would add a “Bonus Week 4.5” where you learn REST before worrying about GraphQL.

More Recent Articles


Thoughts? Feeback? Let me know – @eli4d on Twitter or eli4dcom on Snapchat (I’m still experimenting with Snapchat)


JavaScript Specifics for the “Where do I go from here?” Question

This article is a continuation of the “Where do I go from here?” article with a focus on JavaScript (this is a frequent question I get from the students in my ‘Beginning Programming with JavaScript’ class ). If you haven’t read the previously mentioned article – you should do that first since it sets up the context for what I’m going to say here.

The usual disclaimer applies. This is going to be an evolving post because everything changes in software all of the time. Feel free to contact me with any questions, suggestions, and feedback.

Assuming that you are pursuing project focused learning here are some JavaScript related ideas/approaches.

The ‘no-frills’ project iteration

I suggest that your first iteration of the project use the JavaScript concepts that you just learned. This means using the JavaScript that you know right now. This no-frills iterations will help you understand the essence of your project.

You can continue with plain old JavaScript and an expansion of the ToDo project that we started in class. Or you can choose your own project. As you can tell based on my other article I’m a big proponent of choosing your own project – something that scratches your own (software) itch.

The ‘I must pursue the latest and greatest’ JavaScript ____ \ ____

Many feel that the pace of change in JavaScript (more specifically – the frameworks and approaches to JavaScript) is a never-ending race. It can feel like you’re Charlie Brown, the football is the current must-use/best/must-have JavaScript related technology, and Lucie is that ‘other’ developer who surfs on the bleeding edge with full understanding and a new Medium article about the best framework/approach/’awesomeness’ that you are not using:

This sort of view is known as “JavaScript Fatigue”, and it connects with the two views of JavaScript. The first is that “JavaScript is great!” and the second is that “JavaScript is a mess!” (the State of JavaScript Survey shows this quite nicely on its front page).

The long and short of it is that there is no magic bullet in terms of programming language, frameworks, and technologies. What’s popular today may be gone tomorrow. JavaScript has gotten large enough that you can pick something and specialize in it.

So pick whatever piques your interest. And if you don’t want to pick, then pick a project that interests you and start coding it in plain JavaScript.

There’s a great Theodore Roosevelt quote that applies to decision making:

“In any moment of decision, the best thing you can do is the right thing. The next best thing is the wrong thing. The worst thing you can do is nothing.”

What about bootcamps?

Programming bootcamps are a huge topic that is beyond the scope of this post. Some minimal suggestions:

  1. Figure out if you are the type of personality that would work well in a bootcamp (are you the type that jumps into a cold pool of water or do you slowy wade in?).

  2. They tend to be a large commitment in terms of both cost and time.

  3. Do your research very very carefully since there are lots of questionable ones out there.

  4. If you are seriously considering a bootcamp, you should try your hand with a free one called Free Code Camp. See how well you can commit to daily and weekly work.

I know of 2 students who went to bootcamps for a career change. They completed the bootcamps successfully and did the career change that they wanted. They also found out that the grass wasn’t greener on the other side. One thing about both of these individuals is that they were driven and would have succeeded even if they didn’t go through a bootcamp. In their case the bootcamps accelerated a trajectory that they were already on.

Additional resources

Conclusion

The JavaScript universe is huge. It’s a big mess of awesome. I think Steve Jobs said it best:

stay hungry, stay foolish


Thoughts? Feedback? Let me know: @eli4d


The eli4d Gazette – Issue 018



Issue 018: 2016-11-09

Tech Pick

In Issue 16 of this Gazette, I mentioned a recent well done JavaScript survey. Last week I listened to Sacha Greif, the creator of the survey, on the React Native Radio podcast. There was an interesting part of the conversation where Sacha explained his view/approach to the JavaScript fatigue issue. His fundamental point, that the JavaScript ecosystem has gotten large enough for specialization, was both enlightening and reassuring. In other words, you don’t need to know every nook and cranny of JavaScript and surrounding frameworks/build-tools/fill-in-the-blank to do your job.

Media Pick

Through John Gruber’s site I came across this video where iPhone app developers are reading their 1-star reviews (note that parts of this video are NSFW). While superficially the video is funny, it fundamentally demonstrates the issues of customers and customer support. No matter how much blood, sweat, and tears is poured into software (and to any product for that matter), some customers will always show disdain and disrespect. But that’s the cost of having customers and doing business.

More Recent Articles


Thoughts? Feedback? Let me know – @eli4d on Twitter or eli4dcom on Snapchat (I’m still experimenting with Snapchat)