Tag: JavaScript

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)

Advertisement

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)

The eli4d Gazette – Issue 016


Issue 016: 2016-10-12

Tech Pick

I came across two interesting articles about JavaScript. The first article covers the results of a very comprehensive survey that was sent to 9,000 developers (and how can you not like an article that starts with “JavaScript is great!” and “JavaScript is a mess”). The second article is a humorous (with a large does of truth) post about learning JavaScript in 2016.

Media Pick

I came across a new podcast – Greater than Code. It is hosted by some ex-panelists from the Ruby Rogues podcast. If you’re curious about this podcast listen to episode 2 with Avdi Grimm.

The eli4d Gazette – Issue 012

Issue 012: 2016-08-17

Tech Pick

Dependency Hell applies to both real and digital life. When developing software one frequently relies on other people’s libraries. However, there is a difference between reliance on a robust well-maintained library and using a library for the most trivial of tasks.

At the beginning of 2016 there was a significant disruption in the server-side JavaScript world due to an eleven line NPM module called left-pad. You can see left-pad’s functionality on npm’s site (it just pads a string on the left side). The problem was that many small and high-profile JavaScript applications used it. I found some great perspectives on this issue here:

Last week JavaScript dependency hell was displayed through an amusing article about some high profile Node modules and some ridiculous dependencies within them (the Express hot pocket tweeting one was amazing). There’s no easy answer to dependency hell. I think that it tends to be more pervasive in JavaScript due to JavaScript’s monkey patching DNA which I’ve mentioned in another article.

Media Pick

On a friend’s recommendation, I started listening to the Exponent podcast. It’s a conversation between Ben Thompson and James Allworth about all things tech and society. This podcast is quite different than many others because Thompson’s long-term analysis is brilliant in a (good) mind breaking sort of way and Allworth helps to balance Thompson’s point of view.

Some favorites:

Student Question – JavaScript Array Usage and How to Accidentally Use it as an Associative Array

Overview

In this article, I cover a question that I got from one my students in a JavaScript course that I teach at Stanford Continuing Studies. Monkey patching lies at the core of JavaScript’s DNA and this question/answer is fundamentally about the positive and negative sides of monkey patching.

The Question

The question that came up was regarding JavaScript’s Array object. It is important to remember that the ancestor of the Array is the Object and that JavaScript only has five primitive data types and one complex data type (i.e. object type).

Question phrased by student

The question that came in from the Lab 6 instructions for my class.

Question phrased by student

Clarification of Question – Does debugger show what student is claiming?

The debugger confirms the student’s question. Notice:

(1) We are indeed dealing with an Array

(2) But the length of the array is 0

(3) And yet it contains two items – “w1”, and “w2”

The student question is entirely valid – how can we have an array with 0 elements that has two elements in it (i.e. “w1” and “w2”)?

So Array is acting like an associative array not a typical array data structure.

Clarification of Question - Does debugger show what student is claiming?

Clarification of question – lab section

The question is about the use of the Array (by virtue of [] initialization). Then the use of the Element id

Clarification of question - lab section

Answer

Let’s verify – is the Element’s ID a string?

According to MDN, it is. And indeed for this code “w1” and “w2” are the element’s ID.

Let's verify - is the Element's ID a string?

So what’s going on – part 1

Let’s re-look at MDN’s Array documentation (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array).

(I highly recommend reading the whole **description). Initially, there is usage information, and then there is the description part which includes a very interesting beginning (the “Arrays are **list-like objects“). Notice the “Some people think…” part. It refers to this article: http://andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/ (well worth a read too).

So what's going on - part 1

So what’s going on – part 2

Here is my description of what’s going on: so we are creating a variable that’s going to reference an Array object. The Array object is a descendent of the JavaScript Object (granddaddy of all objects in JavaScript). So this means that we can add properties to the Array object by using [ ]. In effect, we’re monkey patching the Array object to act as a regular Object (since it really is an Object).

So what’s going on – part 3 – simple code example

Let’s simplify this issue through some simple test code. Notice:

  • We’re creating an Array object
  • We’re calling it with the dot notation – just like we would access any property on an object.

So what's going on - part 3 - simple code example

So what’s going on – part 3 – simple code example

The result is that the Array itself is empty (i.e. there are no index based elements). But the Array object has been monkey patched to have the string1 and string2 properties.

So what's going on - part 3 - simple code example

So what’s going on – part 3 – simple code example

Debugger confirms the behavior experienced by the student. There’s an empty array that contains new properties within it.

So what's going on - part 3 - simple code example

Lastly…

Should I have used an Array for the lab exercise? Probably not. It would have been better if I had used a plain JavaScript object. This was a neat (and hopefully instructive) catch by one of my students.

Conclusion

My hope is that this article has been useful to learners of JavaScript (besides my students). Sometimes JavaScript feels like you’re running around with a magic wand and sometimes it feels like you’re running around with scissors. Both feelings are the result of JavaScript’s DNA: monkey patching.

The eli4d Gazette – Issue 005

Hello Friend,

Welcome to Issue 005 of the eli4d Gazette. You can find the newsletter archive at http://tinyletter.com/eli4d/archive and the blog at eli4d.com.

Have a great day!

Eli (@eli4d)

The eli4d Gazette

Issue 005: 2016-05-11

Quick note about upcoming online JavaScript: Registration is opening on this coming Monday (5/16) for my online beginning programming JavaScript course that I am teaching. I will be covering JavaScript fundamentals. For course content info – check out the syllabus.

Tech Pick

Encryption has been a topic of debate from the early Clipper Chip days to now. But is encryption the issue or is it more about device access. Steve Gibson discusses the important difference in his The “Encryption” Debate article. Encryption is math, and this (math) long been out of its bottle. Making encryption intentionally weak makes everyone vulnerable. Strong encryption with lawful and mediated access is the key (pun intended :-)).

Media Pick

So this may seem like a somewhat crazy pick, but it truly is one of the best presentations that I have ever seen (I came across this through John Gruber’s site). It is 4 minutes and 31 seconds of pure awesome with a gentleman named Joe Smith who presents a TED talk on how to use a paper towel. There’s, of course, the ‘reduce waste’ message. But there’s much more from a pedagogical point where Mr. Smith demos his point several times (the repetition concept in play that’s reinforcing and entertaining) while engaging the audience, and giving them ways to remember his approach easily.

Student Question – How does JavaScript Compares Strings?

Overview

In this article I answer a student question that I got in my Beginning Programming with JavaScript course. If you have feedback – please let me know via twitter (@eli4d).

Regarding tools used – I am using JS Bin. If you’re unfamiliar with this tool – check out http://jsbin.com/help/what-is-jsbin. The purpose of this article is to both answer the question and show an approach of how to find the answer.

A Quick Reminder about JavaScript Logic Club

“The first rule of JavaScript Logic Club is that you don’t talk about JavaScript Logic Club. The second rule of JavaScript Logic Club is that you don’t talk about JavaScript Logic club.” 🙂

I know…what does the above quote even mean? I constantly get students with an exasperated expression, frown, and comment that goes something like “but that doesn’t make sense” when it comes to the rules of JavaScript and how it works. In my slightly snarky moods I answer with “when you design your own language that is adopted by all web browsers over a 20 year period, then feel free to make it any way you want” or “well – if you have a time machine, you can go back to 1995 and knock out Brendan Eich for those crucial 10 days, take over, and design your own language – the one that makes sense…I’ll wait for a minute while you do that.”

All snarkiness aside, programming languages are just like board games. Maybe you don’t like the rules of Pandemic, and that’s completely fine. However, your rules of the game won’t be the “standard” of this particular game unless there is lots of adoption and acceptance by other people. There is a vast graveyard of board games that never became popular in the same way that there is a graveyard of programming languages that never took off.

So asking for JavaScript to fit your rules and what makes sense to you is nonsensical. If JavaScript rubs you the wrong way, you can always go to something else that converts to JavaScript (Elm and TypeScript comes to mind).

The Question

So the question that I got from a student was the following:

Small question on comparing strings. Ordering of strings is based on Unicode, got it. If the first letter is equal, are the strings equal? Or does it go letter by letter until it finds inequality? For example, is “made” i and therefore “made” > “maid” ?

The Answer or better said an answer

While one’s initial instinct may be to go and duckduckgo around for an answer. This is a fine approach but in the case of JavaScript, there is much more misinformation than clear information because of the age and popularity of the language. For this article I will refer to Nicolas Zakas‘ “Professional JavaScript for Web Developers” (3rd Edition)*. It’s a thorough reference book that is more approachable than some other heavy duty books (in my opinion).

Note: This information is related to ES5 though the comparison operator will work the same in ES6.

Zakas on String Comparisons

The following excerpt comes from Chapter 3.

So the gist here is that:

  • Don’t use your human logic to associate capital letters as being “bigger” than lowercase letters
  • All strings boil down to character codes
  • Comparison starts with the first letter of each string and goes from there (so there’s no cumulative addition of strings on each side)

Let’s look at “made” < "maid" in terms of what JavaScript gives us, and then we can figure out the character codes to see if they correspond to Zakas's explanation.

Zakas on String Comparisons

How do we figure out a strings character code?

Looking for 'character code' in Zakas's book yields the following.

How do we figure out a strings character code?

What exactly does charCodeAt do?

Off to Mozilla Developer Network (MDN): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/charCodeAt

Interesting – we're dealing with the part of Unicode that is represented in UTF-16 (before things get a bit more complicated). Recall that the student (in his question) had assumed Unicode.

What exactly does charCodeAt do?

Lets go to JS Bin

We're going to use JS Bin to look at the original question revolving around the student's question related to "made" < "maid" and Zakas's explanation. We'll just use the 'JavaScript' and 'Console' tabs.

JS Bin – 1

So according to JavaScript "made" is less than "maid". This is the truth based on JavaScript's rules.

If we evaluate according to Zakas, then the comparison starts at 'd' and 'i' since 'm' and 'a' are the same on both the left and right side of the expression.

JS Bin - 1

JS Bin – 2

Since charCodeAt provides the UTF 16 code unit at a specific part of a string. Giving it one character with or without an index results in the same thing.

Now in the next steps we could put the full string (i.e. "made") and then pick a specific index, but I rather keep it simple and have a laser focus on what we're trying to answer.

JS Bin - 2

JS Bin – 3

Comparing the differing letter for each word – we can see that in the first set ("d" and "i") – 100 is less than 105 so up to this point the answer would be true when asking the question 'is "made" less than "maid".

For the last letters ("e" and "d") the answer is still the same even though "e" is a higher value than "d". What's going on here? Well the comparison stops at the previous set of letters, so this comparison has no effect.

JS Bin - 3

JS Bin – 4

What about "mad" versus "made"? Is "mad" less than "made"?

As the image below shows – JavaScript indicates that it considers this to true. Clearly the first 3 letters on each side of the comparison operator are exactly equal to each other. The only difference is the number of characters. So because "mad" has less characters than "made", it is 'less' in terms of the comparison.

JS Bin - 4

Conclusion

You can find the JS Bin at http://jsbin.com/gopacuv/edit?js,console

We could do much more at this point. For example, we could create a function that gets two strings, then iterates through each one comparing the character codes for each letter and returning the less than comparison based on this evaluation. We could see if the String's localCompare would do a better job in terms of character by character comparison. We could do lots of things, but the goal of this article was to explain string comparison, and this has been done.

Keep your chin up and enjoy JavaScript for what it is rather than for what you might like it to be.

Using the Boring / Old / Popular (BOP) criteria for server side software evaluation

Overview

Episode 14 of the “Under the Radar” podcast covered the specifics of how to best architect a back-end service for you mobile-app, web service, web application, and so on. It’s a follow-up to a previous episode (https://www.relay.fm/radar/13) about the Parse shutdown and the potentially high cost of external dependencies. The one part of this conversation that really caught my ear was around 09:15 and it contained the following interesting approach:

“What you want most of all when choosing server software – if you don’t want to be administering and tweaking your server constantly – what you want is old, boring, and popular. Those 3 things – old, boring, and popular. New and trendy does not always mean better.”

Marco and David emphasize that you should reserve the exciting technology for the customer facing side. Whether it’s your mobile app or a browser side JavaScript framework that will amaze your customers. The back-end of your application, the “infrastructure” should be technology that is boring, old, and popular (lets call it BOP since you can never have enough acronyms) because you want solid reliability in the same way that when you’re home you want a solid source of water and electricity. After all, usually the frontier of front end development is…the front 🙂 (of course this is a generalization for business-to-consumer applications).

A word of thanks

I’ve approached this by looking for numbers and meaning at github.com and libraries.io. Obviously non-github.com projects (like the Apache web server) cannot be looked at in this way because the direct stats aren’t there.

Special thanks goes out to:

  • Marco and David for the content of their podcast and the BOP idea/approach
  • Rachel Berry from GitHub for answering my questions about the best way to interpret GitHub statistics
  • Andrew Nesbitt from Libraries.io for answering my incessant questions about Libraries.io’s statistics

Note that I discovered libraries.io through the amazing Changelog podcast (episode 188). If you’re looking for a tool that will help you figure out your open source compliance (as well as many other things) – check out Libraries.io’s services (I would suggest that you listen to the Changelog podcast to get a clear understanding of Libraries.io’s value).

Lets break this down

If you’re new to this, the first question is where to begin?

I think the place to start is to find some sort of categories that are related to back-end technologies. After all, there’s no point to compare Linux (an operating system) to Ruby on Rails (a web framework).

Two sources that seem interesting in terms of such categories are:

GitHub’s showcases page

In terms of back-end technologies (i.e. server side software) that are shown on the showcases pages the following areas seem more relevant:

  • Web application frameworks
  • Programming languages
  • Open Source Operating Systems
  • Projects that power GitHub (i.e. seeing the components that run a huge enerprise like GitHub – some of these components will likely fit the BOP model; some of course will not fit this since GitHub can afford to hire devs for very niche and young projects)

Note: The image below is an aggregation of the 3 pages of this showcase and the “Search showcases” fields is great to finding a category for a specific project.

GitHub's showcases page

Libraries.io main page

Libraries.io has lots of different ways to look for projects. The keyword section at the bottom seems quite interesting.

Libraries.io main page

Boring, Old, Popular: What does ‘Old’ mean?

While I initially wanted to start with ‘Boring’ because BOP starts with it (and BOP is memorable), I realized that the better way was to start with the property that is easiest to figure out, or at least something that seemed easier.

What does ‘old’ mean in terms of software? Is 2 year old software ‘old’, or does 10 year old software count as ‘old’? (in the case of this post ‘software’ means ‘open source project’)

The definitive answer is “it depends” but that doesn’t help much. I think the better question is “is this piece of software ‘old’ within its category?” In the following examples, we’ll look at the web applications framework showcase on GitHub.

Boring, Old, Popular: What does 'Old' mean?

Rails is 12 years old…that’s definitely old – isn’t it?

Rails is 12 years old...that's definitely old - isn't it?

Express is 6 years old

Express is 6 years old

Laravel is 5 years old…so what gives?

Laravel is 5 years old...so what gives?

Meteor is 5 years old….but is that old?

Meteor is 5 years old....but is that old?

What about the age of the Internet?

Good lord – that depends on your definition. Is it starting from the 1950s when computers were more widely used by governments and universities?

If I’m going to pick a number – I’m going to use HTTP as my criteria so: 2016 – 1989 = 27 years.

What about the age of the Internet?

Damn it – what is ‘old’?

I was tempted to use log2 to help figure the numbers (because logarithms are COOL), but then I thought about what it means to be ‘old’ as an adult and used that to figure out ages of adolescence, young adulthood, middle age, and old age. Here’s an imperfect attempt at figuring this (I use percentage of LEB to help with range indication for age stages).

Note that I’m using Soulver for these calculations (the best-est ‘human’ usable spreadsheet program out there).

Damn it - what is 'old'?

So if I use the age of the Internet as 27

Umm…this is a bit of a chicken and egg thing in terms of current technology and the origin of technology.

So if I use the age of the Internet as 27

Lets make InternetLEB 16

I definitely feel that Rails is ‘old’. What if I take 16 as the InternetLEB. 2000 seems like the ‘right’ year for Web 1.5/2.0 – doesn’t it?

This makes more sense to me but you can picke whatever InternetLEB works for you. So here’s a criteria of judging the age of a project. Based on the Marco/David criteria – you would want a project that is in the middle-age to old-age area. That is the definition that I’m picking for the ‘Old’ part from the BOP criteria.

Lets make InternetLEB 16

Boring, Old, Popular: What does ‘Boring’ mean?

Stepping back for a second to the Under the Radar episode about this whole BOP criteria, the discussion centers around backend software. Software that resides on the server, software that is supposed to be rock steady so you don’t have to worry about your web site or web service falling down on its face on a frequent basis. So we’re talking ‘boring’ in this context, not ‘boring’ as in “uninteresting and tiresome; dull.”

Still, what’s a better definition in this context?

My definition for this is “software that has clarity in terms of usage and is used in many projects because of this clarity”. To me ‘clarity’ refers to a couple of things:

  • how it is used in the context of application/service (i.e. well defined use)
  • used by many others, which in turn leads to clarity in terms of direct documentation or indirect documentation (i.e. stack overflow answers that add up to common and clear usage practices)

Now in terms of hard numbers – I’m not sure how to define and discover ‘boring’ in terms of GitHub or libraries.io. The closest thing that I can think of is the “Dependent Repositories” number from Libraries.io’s SourceRank number (example shown for Rails). I was unclear about the difference between “Dependent Projects” and “Dependent Repositories” and I got the following clarification from Andrew Nesbitt:

*Dependent repos and dependent projects are two separate things, for dependent projects of a rubygem, it’s the number of other projects that list that as a dependencies, for rails there are ~7940 other rubygems that depend on it: *https://libraries.io/rubygems/rails/dependents

For dependent repos, it’s every Github repository that has rails listed as a dependency in it’s Gemfile or Gemfile.lock, which there are around 60,000: *https://libraries.io/rubygems/rails/dependent-repositories *

I asked Rachel Berry if there was anything equivalent on GitHub and there didn’t seem to be anything that was directly equivalent. She suggested the use of code search to provide a rough statistic. So something like https://github.com/search?utf8=%E2%9C%93&q=gem+rails+path%3A%2F&type=Code&ref=searchresults or https://github.com/search?utf8=%E2%9C%93&q=%22gem+rails+5%22+path%3A%2F&type=Code&ref=searchresults could provide a possible alternative. The problem with this approach is that you need to know how a dependency is included and then deal with the various variations in inclusion strings (besides other issues like different package managers for different software).

Overall, I don’t think there is any “hard” number that can easily capture the ‘boring’ criteria. I think that in this case ‘boring’ is really the result of looking at ‘old’ and ‘popular’. So instead of the BOP criteria it should perhaps be (B)OP or B/OP. Moving forward from this point – I’m going to go with (B)OP.

Boring, Old, Popular: What does 'Boring' mean?

Boring, Old, Popular: What does ‘Popular’ mean?

I left the “best” for last – POPULARITY. What the heck is ‘popular’ when it comes to the BOP criteria?

Is popularity based on GitHub stars?

How useful are GitHub stars in evaluating popularity? They seem somewhat transient and unreliable for this criteria.

Is popularity based on GitHub stars?

What about popularity based on GitHub forks?

Forks by their very nature are other people’s experimentation with a project. Of course there could be upstream contribution but how much of forks are actual contributions back to the project?

Forks seem like a way of learning and modifying a project’s code but I don’t think that they have anything to do with popularity.

What about popularity based on GitHub forks?

What about project members?

So the “Members” graph is a visual representation of the Forks number (i.e. “members” of the fork network). It’s another view of forks, and therefore its ‘popularity’ usefulness is questionable.

What about project members?

What about a project’s contributors as a reflection of popularity?

I think that this is similar to forks – specific people being interested in a project for their own reasons.

What about a project's contributors as a reflection of popularity?

Something that ‘trends’ is popular – isn’t it?

Something that is trending may reflect momentary popularity. But it is certainly in conflict with the ‘old’ and ‘boring’ criteria, so this is definitely not a good measure.

Something that 'trends' is popular - isn't it?

OK – I FOUND IT – I KNOW THE DEFINITION OF POPULAR!

Actually I don’t but I’ll take a run at it anyway.

I don’t know what’s popular or how to best evaluate popular in terms of the BOP criteria. Maybe it’s one of those I’ll know it when I see it things. Still, it doesn’t help anyone who is new to backend software infrastructure. The best thing that I can come with at this point is Libraries.io’s SourceRank number as a decent data point for popularity. Is it the best? Probably not. But I don’t see anything that’s better at this point.

Note: We need to keep in mind that log values are used in the creation of SourceRank so a difference of 2 between the SourceRank numbers of two projects could be quite significant

OK - I FOUND IT - I KNOW THE DEFINITION OF POPULAR!

(B)OP Comparison Example

So essentially – the (B)OP criteria boils down more to the O and P, since B falls under O or P – your choice.

  • Old = age based on the previously mentioned age/stage criteria using the year 2000 as a baseline
  • Popular = SourceRank at this point or using a GitHub source search if the project is unavailable on libraries.io

With the above in mind – lets compare Rails and Express.

The (B)OP criteria for Rails

So for Rails we’re looking at:

  • Old = 12 years with an age factor of %75; so its at middle-age about to hit old-age
  • Popular = SourceRank of 28

The (B)OP criteria for Rails

The (B)OP criteria for Express

So for Express we’re looking at:

  • Old = 6 years with an age factor of %44; so its at middle-age
  • Popular = SourceRank of 26

The (B)OP criteria for Express

Which to choose?

So all things being equal (discounting for things like experience in Ruby/JavaScript which could easily change the decision), the choice in this case would be Rails. This is due both the O and P factors. Granted, other comparisons might be much closer, and then it comes to preferences of programming language, educational interest in a particular project or technology, and time for experimentation and implementation.

Conclusion

So in summary – make your back-end server and services the best they could be by choosing the most (B)OPish (boring, old, and popular) technology when looking at the server side level of your technology stack. This advice would seem to contradict the “I want to develop on the latest and greatest technology”, but it is the best path to system administration sanity and it takes away nothing in terms of the fun part of your product and using the latest/greatest in there.

Some other resources that I came across

While researching and reflecting on this post I came across some resources that might be useful for those that are looking for ways to distinguish different projects (this is not limited to server side type of projects):

Some other resources that I came across

About this post

This post was written by @eli4d and it originally appeared on eli4d.com on March 10, 2016.

The Laravel Podcast Episode 42 and the Meaning of …

I really enjoyed last week’s Laravel Podcast episode 42. Now since it is episode number 42 – I expected it to contain the answer to the ultimate question of development.

Now when you listen to the episode, you might think that the ultimate question that’s being answered is “which is the best object relational mapping approach/pattern – ActiveRecord pattern or the Data Mapper pattern?”

Or perhaps the ultimate question that’s being answered is “Should the ‘Single Responsibility Principle’ be violated when it comes to ORMs?”

Of course you need to listen to episode 42 to make your own decision. Perhaps it’s all ORM drama and dogma that is just a mystery wrapped in a Twinkie.

Personally, I think that the ultimate question is “how should you approach feature creation when it comes to software development?” And the answer is stated at the 46th minute of episode 42 (if only it was the 42nd minute…it would have been perfect…it’s time to repeat ‘serenity now’^100 and come to terms with this lack of symmetry). So what is the answer is:

“Don’t do it until you need it.”

Sounds simple – doesn’t it?