There are many reasons that caused me to land on Ghost.
It’s no secret that JavaScript is my language of choice. I didn’t need to read further, but when I did I got even more jazzed. Ghost uses Handlebars for templating to separate presentation from logic.
Again, JavaScript. My machine is pimped out for JavaScript development, it’s a very natural fit for me to run an instance of my blog locally for testing and hacking.
I’m really coming to like Markdown, but still lack enough proficiency to make me happy. Using it to write posts should improve that.
I’ve tried many platforms, I’m sure Ghost won’t be my last. For this version of the blog I was using Octopress, and really was not displeased with much of it. There was one large issue for me however – I couldn’t blog from any system I happened to be using. Ghost solves that.
]]>My initial response, my off-the-cuff conditioned answer, was something along the lines of describing how they fill an important role in the software development ecosystem by being the group that performs the grunt work. Now keep in mind, this isn’t a question that I had previously spent any time thinking about and as usual let my mouth answer before my brain.
I followed that up with a bit more thoughtful response, after a few seconds of thought, the most I’d given it. I responded that I thought a Junior Developer was also important as someone who I can learn from. I likened the role to that of children and how we can see things differently if we allow ourselves to see things through their eyes.
Now I’ve spent more time thinking about it, not enough yet to be sure, but at least a few hours letting my subconscious noodle around on it last night and today, and I’m stuck on what exactly makes a Junior Developer in my eyes and for my definition.
A Junior Developer…
…very well might be a faster coder than me
…might be aware of more, or at least different technologies than me
…could be able to code in more languages than me
…likely has more open source contributions than me
I think what differentiates me from a Junior Developer might be that I’ve failed more.
Thomas Edison once said (or at least is attributed to saying) something along the lines of:
we now know a thousand ways not to make the light bulb
For each new project or task I’m assigned, I bring to it all the failures I’ve collected over my career. I can’t say I won’t repeat those failures, but I’ll likely find my way out of them more quickly having experienced them before.
So what differentiates me from a Junior Developer? My failures. Now that I have a definition I can take a fresh look at the initial question and discover what I think of Junior Developers, what value do I think they hold.
A Junior Developer might code faster than me, there’s value in that. A Junior Developer might be aware of more or different technologies, there’s value in that. A Junior Developer might be able to code in more or different languages than me, there’s value in that. A Junior Developer might fail more or in different ways than me… there’s value in that!
If I always can allow myself to learn from failure then it doesn’t matter where that failure comes from. If I can learn to really embrace failure then I’ll become a better developer. If I can learn the thousand different ways to not make software, then I’ll be one step closer to learning the better way to do it.
There’s value in that.
]]>I was trying to think of the last time I clicked on a save icon, or hit ctrl-S to manually cause a save to happen. Usually anything I’m working on is auto-saved now, from email drafts to coding with Sublime Text 2. The manual save operation has become a dinosaur action.
Inside that discussion post on branch.com PJ Onori suggests that “saving will be more about explicitly calling out a specific point in time.” I can see a lot of value in that. Instead of saving whatever it is we’re working on, we’ll snapshot it. It’d be as if we had a type of revision control system for everything we create on our laptops - an email that I’m writing, or a blog post, doesn’t need to be tossed into a repo on github as I work on it, and I no longer need to worry about manually saving progress, but capturing its evolving state on a timeline could be of great benefit.
]]>Daniel Lamb recently posted his demo of Crockford’s idea. Paul Irish gave Daniel some exposure in a Google Plus post and that started some conversations flowing.
I wouldn’t want to switch to Scope Context Coloring exclusively and give up syntax highlighting. I’ve been thinking of a toggle between the two but even that seemed cumbersome when something like code coloring should be automatic and without developer involvement. And then David Li had the most brilliant idea of using opacity instead of color for scope. Syntax Coloring coupled with Scope Context Opacity gives us both, without choosing which at which time, and also helps by keeping the current scope more in our attention focus. It reminds me of iA’s Writer which remove all the visual clutter to help you focus on the current thought.
As far as I know this doesn’t exist yet, at least not for Sublime Text 2. A perfect excuse to dust off some Python coding chops!
]]>A primary new feature in AngularJS is support for animation in templates. ”Animation,” you cry?! “We aren’t writing games!” Animation isn’t just for games, if used with care animation in a web app adds that last finishing touch that really says polished. The animations that have become so common in native mobile apps have raised the bar for web apps, even in the desktop browser.
The video in this post’s subject link is an introduction to animation in AngularJS. The point of the talk is to demonstrate how easy it is to animate. Remember that thing about ease… just like for unit testing, the more easy something is the more likely it’ll get done. If adding that animation is easy, it’s more likely that it’ll make its way into your web app. (but take care not to make your app look like an early 1990’s PowerPoint presentation!)
The source to the demo can be found at Miško Hevery’s github repo.
]]>The official github help page.
]]>The documentation indicates that your folder structure must include a public folder inside your project folder. This would have conflicted with the directory structure of the application that I’m contributing to, so I simply wrapped my project folder with a company folder, which in turn holds the public folder:
1
|
|
or another way to view that is:
1 2 3 4 5 |
|
You still need to create the symbolic link from your site’s directory
1 2 |
|
and now you simply access your static site via:
1
|
|
Of course the easiest (perhaps better) solution is to install the powder gem and manually bring down the pow server when working on your non-pow projects.
]]>