Once upon a time, in a forgotten little green valley there was a small kingdom, ruled by an old and wise king. The people of the kingdom loved their king and praised him constantly, albeit the heavy taxes that burdened their life and debts that enslaved them and their children for all ages.

And then one day, a cry was called, challenging the king’s authority. Nobody expected that. Especially the king, let alone his unscrupulous tax collectors who feared that any threat to the kingdom is a direct threat to their livelihood. But the biggest shock came when it turns out the cry came from none other than the king’s very own beloved son. The people of the kingdom were baffled at the meaning of this as the king loved his son and son loved his king in return; but the cry was clear as the lake’s face at the early mornings – The son promised all those who wish to pledge their allegiance to him a relief from the debt owed to his father. Freedom, at the price of servitude.

The king’s council didn’t know what to make of this and what shall be done with the disobedient prince and his impious followers and as the king kept his silent, as he always did, they’ve made the best decision that they could: “The prince will be banished, yet his ruling will preside”. At first, his devout followers were punished severely but as time went and as their numbers grew, it became less and less horrific. It seemed that the king never vindicated or rebutted his son, although those that are debating about this still would claim otherwise. A few even suggested that the debts were meaningless if they can never be repaid, but none of this really matter as this happened long time ago in a place very far from here.

Debt slavery (or “debt bondage”), however is something that still exists in our world today. It is a person’s pledge of labour or services as security for the repayment for a debt or other obligation, where there is no hope of actually repaying the debt. The services required to repay the debt may be undefined, and the services’ duration may be undefined. Debt bondage can be passed on from generation to generation. Today, debt bondage is the most common method of enslavement with an estimated 8.1 million people bonded to labour illegally as cited by the International Labour Organisation in 2005 (source: wikipedia). Debt bondage has been described by the United Nations as a form of “modern day slavery” and the Supplementary Convention on the Abolition of Slavery seeks to abolish the practice. To lean more about modern day slavery, visit the anti-slavery website.

Advertisements

So Microsoft purchased Github, and everyone are fussing whether it’s a good thing or a necessary evil. Github, which is a company like any other company has 3 major benefits

  1. Its name makes it associate with the tool Git, thus making the default go-to online repository.
  2. It was the first of its kind
  3. It was widely adopted by the open-source community.

Microsoft, which is a monstrous corporation like any other has its own quirks and perks:

  1. It’s responsible for Microsoft Windows; and office
  2. It promotes its own dev-technologies like c# and typescript.
  3. But it also did good things like X-Box, VSCode and MS-Paint.
  4. The have defiled Skype.

Will Github share the same fate as Skype? not necessarily, it’s important to remember that it wasn’t Microsoft that killed hotmail, it was Gmail, and that not all acquisition instantly kill a product (i.e. Youtube).

So what might go bad? Meta-data regarding developers’ activities will sip through to Cambridge Analytica; Microsoft technologies will be pushed down our throats; The service will deteriorate and eventually die. What might go right? The service will not die out of bleeding money.

At the end of the day, there are alternatives to github so I don’t feel coerced yet to break down into sobs. Not just yet, at least.

A URL (stands for Uniform Resource Locator, but surely you knew that) consists multiple components scheme:[//[user:password@]host[:port]][/]path[?query][#fragment] (for example – https://admin:1235@127.0.0.1:4200/languages/javascript.html?lang=en#es6).

There’s an interesting history to the evolution of URLs but I would like us to focus on the path part though as the word itself implies a certain meaning – the path represents the location of the file we are now browsing, but what about single-page-application? it’s the same page giving different values as we use it. So we can either ignore these values (and keep the URL static) or we can update the query part of the URL (or a update the path, which is sort of lie, but we’ll get back to it)

Updating the query meaning exposing something to the user that he doesn’t care to see. For her there, is no difference between path and query, she’s only interested in the results. and Should the user care that the file we’re serving her is an html file or a doc file? not really…

So the URL can represent a location, but it can also represent a state:  if we imagine our single-page-application as a finite state machine let’s say “start”, “playing”, “game-over”. the URL can indicate in which state we are. It actually makes a lot of sense as it means I can copy-paste and send this session-state to someone else to pick up where I left off, for example. Although in all fairness, states are usually not really transient – user-specific information is usually not part of the state (but it should be) or the state simply contains too much information to be described in a single line. So we can say that the URL contains the user-session ID, pasting it to a different machine (and having the same user credentials) I should be able to continue my work, that can be pretty slick. How many times did a friend tried to send you specific search-results and all you got was the empty search page? this is something can quite useful…

Another meaning we can give to URL would be of actions. Imagine you can you can tell a web-application what to do, like a CLI (command line interface), for example gmail.com mail friend@somewhere.com "great idea!" "hey, loved the new designed" and that’s it, email send without the need to actually visit the website. It’s a bit of a superuser-hack as normal users won’t bother themselves learning each website internal language.

Or maybe the URL should be completely hidden from the user, which is pretty much how Safari treats its URLs. Imagine every online element has its own unique ID, a crazy 32-byte string representing it that has no decipherable meaning, but computer can decode it to find the exact computer and command they need in order to retrieve the right content. Nowadays, magazine ads that provide online content will refer their readers to google or facebook their product, or provide a QR code, instead of giving a complicated URL.

Personally, I prefer to have my URLs meaningful, whether as a state-representation or an action, but that’s just the geeky superuser part of me and at the bottom-line the average user doesn’t and shouldn’t care about the URL.

EmberJS has a strict filename convention. It actually has two, for your choosing: if your template and route are at the same folder they should be named template.hbs and ​​route.js respectively but if the template is in the templates folder then its name should match the route. It makes sense. sorta. I mean, why actually should anyone care what file names I am using?

I understand Ember’s logic as it can easily find items by expecting their name to follow its conventions; but this is done at the build stage, right? It’s a critical point, because we would like to bundle all our javascript files into a single file so the file names are not relevant on time. When we’re bundling, we’re creating a big key⇒value map and whenever we need another module we just ask according to the key. For Ember, the key would be the file name. For any other framework, they’ll explicitly ask for the key.

I think it’s an issue worth discussion because it’s limiting. Let’s say I’m using Ember’s Pods (i.e. template and route are at the same folder) and now I have 10 templates open, all named of course template.hbs; which means that by glance I can’t tell where is the template I want. Alternatively, if I found the route I want and now I’m looking for its corresponding template, I’ll need to look for it in a folder other other dozens templates. Yes, I can use fuzzy-search but wouldn’t my life be much happier if the file was simply next to its router?

So let’s say we’re using another sort of key for the bundler to find the right piece of code, how then should I name my files?

  1. The file name is a tool for the other developer to find your file. I really hope you can easily find your files, so a meaningful filename is important for other humans. I would suggest the general line of specific-to-general in describing the file. for example, “login-dialog.template.html”: start from very specific descriptor – login and ends with a very wide descriptor – the file type html.
  2. Your life, as the developer, would be much easier if you stick to small-case, else you’ll put yourself into hell trying to figure out if “Il” is “ii” or “LL” and why you can’t find your stuff.
  3. I’m pretty sure there are plenty of other conventions out there, but the bottom line stays the same – pick whatever works for your team and yourself.

As bonus topic, it’s interesting to see how bundler find their own files. here are 3 strategies:

  1. Dumb: Given a folder, pick all files that match the criteria (*.js for example) and bundle them together; Assume that all files access global variables so they’ll do their magic if their module isn’t called explicitly.  Working with global is a bad idea.
  2. The Ember approach: Scan predetermined folders and assume all files play along as you’d expect.
  3. The tree approach: Given a file, it will contain information regarding its dependancies, relative to source folder, while the bundler will translate it to a named-module or redefine the relative path as needed.

And a final note regarding testability, neither approach promises ease-of-testability and any convention can be twisted and exploited to create bad-code. As a general rule you should avoid using singletons that cannot be replaced at test-time but this has nothing to do with your filename or the way your file bundles together.

There is a certain romanticism when talking about the wild west, mainly regarding self-reliance and inner strength, to the extent that it became a myth in which the frontier is described as “…unlimited opportunity for the strong, ambitious, self-reliant individual to thrust his way to the top.”. But I would like to focus on the wild’s west lean to Anarchism. Yes, there was a central government but out in the wilderness its umbrella of protection, services and enforcement was very limited. As mentioned, There weren’t shoot-outs every midday and people managed to get something going. And then came modernism  and offered those cowboys comfort and relief at the mere price of their liberties.

Personally I think the web is the future (well, probably more Tor, but let’s not be picky about it now), and javascript is our current frontier. On the one hand it means a lot of challenges and opportunities but on the other its lawless-ness that might be off-putting. A centralised government, for example would be what Sun is to Java or Microsoft to C# – essentially they make the rules, and they enforce them using IDEs and compilers that restrict you from writing your code in any way other than what they permit. With javascript we don’t have that, we can write whatever crap our heart desire.
Maybe it’s not for everyone but being able to have it is what, I think, makes javascript the best language in the world.

Along came Frameworks, and they are plentiful and they want to do the same thing – put some law and order into javascript, essentially telling you it’ll be much easier to send your kid to a public school if you have a government-funded bus as oppose to the alternative in which there’s not even a school to begin with.

As I’ve mentioned before, I don’t like dependencies and I would be scrupulous about using them – not only because they replace one concern (of writing code) to another (keeping an eye on API changes) but Frameworks also force you to abide to their sort of government and their behaviour (be it React that mixes between Style and functionality or Ember that forces you to a specific structure and a way of thinking).

A thing about these authoritarian frameworks that they are generalised one-solution-fit-all; and as far as I’m concerned that automatically leads to inefficiency. I think developers should pick up their own toolsets to get the work done, either by creating them on their own or picking them up as they go, but I don’t like the idea of a one-stop-shop. Should you still want a framework just to get something up in air in zero-time, I’d go with Vue.js as it’s light-weight, relatively short learning-curve and isn’t so much authoritarian.

But seriously, I’d avoid frameworks if possible. 90% of web-applications are simple and should be super-efficient so aside for developer’s laziness there’s no real reason to use a framework – and for big system where performance is crucial – I think you’d still be better off to write the dang thing yourself.

Personally, I think promises failed to deliver their promise of a better organised code.
Their initial intention was to reduce the callback-hell, but this hell is caused only when using anonymous functions. I was investigating how to promises handle errors; consider the following code:
function test(input) {
    return (newPromise((resolve, reject) ⇒ {
      if (input > 0) {
        resolve(`${input} > resolved`);
 } else if (input < 0) {
 reject(`${input} > rejected`); 
 } else { 
 throw(`${input} > thrown`); 
 } 
 })
 .then( output ⇒`${output} > reached`, 
 rejected ⇒`${rejected} > reach/reject`) 
 .catch(output ⇒`${output} > caught`) 
 .then(output ⇒ `${output} > finally`));
}
When is “caught” will be printed? whenever I throw an error on any of the previous then() functions? apparently not, because I catch it earlier on (at “reach/reject“)
test(1).then(output => console.log(output)); // 1 > resovled > reached > finally
test(-1).then(output => console.log(output)); //-1 > rejected > reach/reject > finally
test(0).then(output => console.log(output)); // 0 > thrown > reach/reject > finally
Actually promises are slightly overcomplicated then they should have been
  1. then() doesn’t really need the second argument (which handles rejections) – we’ve could used .catch(). if that second argument would have handled only rejection from the previous then it might have been useful but as it’s not – having it just makes reading harder.
  2. There’s no real need for resolve and reject – a simple return (like any then()) function could have replace resolve and a throw could have replace reject. This can actually be resolved quite easily with a helper function
function promise(firstThen) {
  return newPromise(resolve=>resolve()).then(firstThen);
}

//...
(promise(() => { console.log('tada!'); }));
and no more resolve() and reject() 😎

 

I created a small script that gets a filename (html, css or javascript) and a RegEx pattern for an “import” command and it return a list of of the files’ dependencies (recursively). It works great. But then I realised that when I write code, I often first add the link and only then add the actual file. This leads for the mapper to scream that the file is missing. So let’s talk about error-handling strategies:
  1. If there’s an error, stop the entire process. As I mentioned error might occur quite casually and as I don’t want to educate my user, the system should be more forgiving
  2. Ignore errors, continue as is. That sounds like a bad idea on the get-go. If the end product isn’t good because it had errors in the process, I would like to know about it
  3. Log internally and continue. We can log to console whenever there’s an error and then ignore it and to be fair, for my usage it might have been good enough, but the problem is that this strategy cannot be tested as the logging is done internally.
  4. Ultimately my solution was Delegation, whereas the default option would be to log the error internally but if given a delegate, the process will let the delegate handle the error and it would decide whether the process should stop (by throwing an exception or not).

On a bigger scope, I think these strategies can be applied to real-world problems that we’re facing – whenever something goes wrong – do you break-down and cry? ignore and moves one? make a note and check if anything is broken before moving on?

Of course I’m biased towards my winning strategy (I may change my mind from time to time, but I’m always right), but the other strategies do have value and can be useful in some conditions – where, for example, you simply cannot allow yourself to continue once an error has occurred or perhaps you cannot allow yourself to stop?