Uncovering technology – with Jukka Paulin
One day the Clandestine Rock Docks were visited by this rather mysterious figure. He barely moved his lips but was able to clearly convey his wishes of a new kind of slick starfighter..
David is one fantastic project that somehow draws my attention.
There’s probably 2 reasons for this. First, it was the first project where I submitted some code over GitHub. Second, I’ve always been fascinated by the seeming chaos and mesmerizing scope of software nowadays: we’re easily looking at beasts sized at least several thousands of lines of code, often even something like a half a million or million lines of code. How the hell we’re able to pull off the stunts? I mean, it basically sounds on the outskirts like pure madness. However, there’s some shared communal logic which especially now, in the days of readily available source code beyond our wildest dreams, starts to emerge and sorts out the individual packages so that everyone has its own place.
“Den glider in!”
I know that you’re looking for a fresh view to how the Great JavaScript Boom of ~201x happened, so… OK, I know you’re not looking tohear that, but for the sake of completeness, it just has to go here:
Oh, sit down, Josh. You too, Sara. We’re about to embark on a fascinating story into the land of unicorns and hipsters.
1996 Netscape Communications. 10 days time from inception to release. Brendan Eich. Great success hack.
Next: 14 years of mainly onMouseOver shite. Nothing significant.
2010 onward: probably some mutant material hit Earth, and JavaScript evolution got miraculously started. The language gathered an ever-increasing wide audience with soon unbelievable hype and fervor. In 2015 if you didn’t know JavaScript there was 0 jobs for you. Ok, a bit of exaggeration. Not much.
Starting from somewhere around 2011 the world of JavaScript knitting got a big kick in the butt with npm.
Sometimes the landscape of programming has epic battles, but this time it was something very benign. You see, ‘npm’ is the Node Package Manager (or something like it, anyways). All other programming languages, and most notable, PHP and (heck, is there any other remarkable web dev language… Oh, yes, Ruby/Rails of course) Ruby had their neat package managers.
JavaScript was on its haphazard way to become newly minted emperor of the web. At least on the front-end side. JavaScript stumbled somewhat however on the ease of use; well, in fact, it had a few places that slowed the path to success: its rather peculiar sparseness (ie. the lack of powerful language features that had been bread and butter for years in other languages), and it also clearly lacked a simple way to “include shared libraries”.
All JavaScript methods of ‘library inclusion’ back in 2012-2014 were sort of a bad hack; some of those hacks were so weird that one would assume only the original inventor knew how they worked.
Anyways, during this heyday of innovation npm had a social calling: it just fit like a glove.
So, let’s get a rehash: “npm” became one of the most essential tools for JavaScript coders – it installs, updates and enables all kinds of management around JavaScript packages. Most developers benefit from npm as in the role of “clients” – being package consumers. Others will be using npm to publicize their own packages.
With npm, you could easily test out ideas as a developer; by borrowing code, testing it out in your own piece of code, and if you were dissatisfied with that particular package, just uninstall it and go again with another one. npm would track your dependencies in a file called package.json
In plain English, ‘david’ simplified a very arduous and ugly process of manually hunting and installing zipped JavaScript packages. david builds on top of npm, by using npm’s API. David has a few interesting functionalities:
Be back, soon!
I’ve lived around it, you could say, for my entire life. Sometimes closer, and sometimes farther away. 
Helsinki is such a fascinating place after all. When discussing things with friends, there’s often been the topic of how different places feel, what’s good about each and so on. Helsinki, they say, is great if you don’t experience it every day – that’s what I’ve been told.
I served in anti-aircraft troops during conscription. That was mainly designed to fend off things threatening Helsinki.
During studies I went to Helsinki many times, although Otaniemi is located in Espoo. Back then Helsinki represented the street life, bar life and generally, “life”. As it still does. I almost daily commute through the downtown area, in Kamppi, switching bus towards Lauttasaari.
Here’s to Helsinki!
Welcome to Nuts&Bolts with Linux, or ‘N&Bx’.
I’ll keep sharing some of the things that have recently found. It’s amazing how rich a GNU/Linux system actually is. I’ve jokingly said many times that you can either play games, or just explore more and more of a Linux. Either way you won’t run out of things to do.
The shell is really what it says; kind of cover, an enclosing; “world of its own”. The shell’s purpose is to interpret commands and act as a middleman between users and the core of the operating system. Without a shell we’d be really hardcore enthusiasts, like those of the 1950s who knew how to program a computer by switching levers and knobs on and off.
The most usual that we think of with a shell is interactive use: you type commands, and the shell is your tool to speaking with underlying OS. A shell can contain a lot of amenities and amendments that we take for granted, and some that are probably still undiscovered by many users.
Second kind of usage is executing a single command with a shell. You’ve probably seen those
sh -c "echo '1' >> file"
kind of commands that take advantage of the shell’s rich internal commands, pipes, and combine these sometimes with program execution.
Third use case is where a script uses a shell as an executing environment. This is the batch mode; for example in Linux, the commands that regularly run via scheduling, take a shell underlying, which sets a execution environment, and then the payload command runs on top of that. The payload itself can be a shell script, internal shell command or an external binary (program).
Bash had been my default shell in Linux for years. I had not even thought the decision originally as to ‘why’, but I guess bash seemed somewhat more sophisticated than the standard ‘sh’ shell.
Next in N&Bx we’ll check out how does bash set up the “environment” and its own options. Until then, adios!