Add to the list a couple of other things that I feel the need to learn for my side project:
Angular 2
TypeScript
But I am having the darndest time with TypeScript. Not so much the syntax or language or ecosystem. Especially for ecosystem, WebStorm has been enormously helpful.
No, with TypeScript I am struggling with debugging and wrestling through problems in the browser. So far my journey could best be described as 7 steps forward and 8 steps back.
By which I mean, there was an initial phase where I thought I knew what I was doing - this was validated by "successes" where I got actual code that I wrote transpiled and working in the browser.
But as I ventured further in - mainly to get the Angular http module working. I have been deconstructing my working code more and more to strip it down to the bare bones and try to understand why a couple of things have gone wrong.
The end result is that I will understand the whole thing better, I suppose. But it is still very frustrating, and I am not yet at the end of my "journey backwards", so to speak.
Also, I'm removing one:
Sqllite
Simply not worth the time for what I'm doing. And I already understand a lot about databases, if I ever really want to pick that up.
In software we leverage some construction terms when we talk about software projects.
Greenfield - a new software project that is not built on a previous project. AKA - blue sky, carte blanche.
Brownfield - a project that is adding onto an existing product. AKA - enhancements, feature work, new version development.
I am going to add to this the idea of Bluefield. This is a project that is a rebuild, from the ground up, of an existing application.
This is very particular to software and I don't know if it has a counterpart in traditional construction.
This project is neither Greenfield (not brand new because it must fulfill requirements of the original system) nor Brownfield (not built on an existing product).
Why are the fields blue?
Let's say that Bluefield projects are akin to the blue sky of a new project (you often have a clean slate on technology), but you can have some sadness about the passing of a tried-and-true system that served you well for some period of time.
Blue is also associated with harmony, faithfulness, and imagination all traits that should be valued in our rebuild project -
Harmony in important features.
Faithfulness to the business intent.
Imagination required to overcome project challenges.
I see the converse of this (Code is Poetry) show up here and there on the internet. I agree with the sentiment behind it, which I will sum up this way: Code is Art.
I agree with that, but I think we should let code be its own art.
The art of writing eloquent code is more closely related to construction, engineering, or architecture.
Is the Eiffel Tower beautiful? If you think it is then you can probably appreciate the beauty in a well-written piece of code.
This is the Modernist idea of beauty in materials or beauty in the way materials may interact to produce an effect.
Code isn't poetry because code has no sound, and poetry is about sound and words.
Code can't be pronounced, spoken, or voiced. At least, I've never seen anyone do it in a way that made sense.
It might be interesting to see someone try.
But what about the title of this blog post, which is looking at it the other way? How is poetry like code? How are the things that go into development - design, testing, compilation, and execution - analogous to things that happen in the writing, reading, and hearing of poetry? That to me is (mostly) unexplored territory and seems interesting.
Jonathan Fries on .