To do web dev, I need an incantation:
"ES6, Atom, Mocha, Mongo, V8, Node + Promises, npm, Express, Docker, Grunt, Ractive, VMware, Git, Gitlab, JIRA!"
Together, these technologies form a toolchain and a stack. (To clarify: each of the above are different programs, or frameworks, all used in making one other program. Each link in the chain has quirks and an internal mini-language to learn. And this is all besides the home-grown scaffold the target program actually uses / consists in.) Two months ago, I'd no idea that people use a dozen widgets to get large projects up and talking; I had no acquaintance with most links in the above chain.
But I'm being melodramatic: we use these because the project I'm working on is so large; all of the links make my life easier, and most are unobtrusive (to the point where they don't need launching, even). And it is easy enough to get by with only a fewer components. It's just that I learned code by writing toy single-thread synchronous desktop applications first, and never wrote without stabilisers (an IDE) that did all of these tasks for me, silently. This was a bubble.
Anyway, if you're interested, here is an example of a very modern web-dev toolchain:
Coding:
- Editor: Atom
- Linter (validator): JSHint in Grunt
- Debugger: V8
- Database: MongoDB
- Test framework: Mocha
- Web framework: Express
- Minifier: Grunt
- Linker: Grunt and V8
- UI Template: Ractive
- VM: VMware,
- Virtual container: Docker
Runtime platform: Other:
- Package manager: npm
- Library for superior asynchrony: Promise.js
- Source control: Git
- Repository manager: Gitlab
- Project management: JIRA
************************************************************************************************
This post actually started out as a little rant about one particular obnoxious buzzword in an industry full of them: 'the full stack developer' (i.e. someone totally skilled in every layer of development). But I was confusing the above toolchain (the production line) with 'the stack' (the product), and got into the former topic much more.
Anyway, trying to understand everything – 'working your way down the stack', nearer and nearer to bedrock protocols or hardware – is as admirable a goal in computing as it is anywhere: it is good to be less complacent, more aware of The World, even without the practical benefits it yields (in fixing problems faster and so on).
In this case, though there is the additional matter of appreciating what one is actually doing when one deigns to order 1 or 8 billion robots around, badly.
'The Mirror of Nature and the Image of Art' (1617) by Robert Fludd
************************************************************************************************
Update for October 2015: a new job, much more organic system.
- Text editor anarchy.*
- Laravel: PHP web framework.
- VM: Vagrant over VirtualBoxes. Here, replaces Docker.
- New Relic: Server manager: identify slow queries, APIs, lines.
- Git and Gitlab : source control.
- Kibana: Centralised analytics
- Jenkins: Continuous Integration watcher.
- PHPErrors
- PHPMyAdmin: **
- Phing: PHP build manager. Also Capistrano: Fancy modern build manager.
- Slack #ops: Just a chat suite hooked up to the rest to shows all the build and migration messages in one place.
- Navicat: DB editor
* One person is stuck with DreamWeaver because of some nice legacy code they can't be bothered porting.
** What an awful Web 1.0 name.
Actually I got to argue against the portability of high-level code.
ReplyDeletePortability is a human problem.
It's extremely unlikely the VM works exactly the same everywhere.
But Java! Of course, Java is venerable. Backed by billions of dollars over many many years. You cannot say that about many technologies.
You may be shocked in a few years. Code in "rapid" languages needs to be maintained constantly. In 6 years time, you may struggle to get your program working. You will need to find ancient versions of the interpreter. Of all the libraries. Hell, of the web-browsers that you use to interact with your program.
Now that's fine when you're working a day job. After all, the business exists to maintain these programs.
As a single developer, working on something in your own time, that you feel is personally important? Something that you're not doing to make money. Don't write it in something trendy and new! If you use C, C++, and choose libraries carefully, you'll find that in 6 years time, when you want to show the program to a new friend. Or at a job interview. It will still compile. It'll still run, on every system you built it for, because all it needs it the operating system.
I am wagering that the Go developers understand this problem. They are very cautious with adding new language features. Got my first go program to compile yesterday. Here's hoping it will still compile in 2025!