I’ve been toying with a total and complete rework of this site for a little while, but to be honest I’m not sure what platform to pursue. Do I chose a new CMS? Do I go with Jekyll or some other static file variant? It’s difficult to decide–I know I’d like to learn a completely foreign and new skill set. For the time being, however, WordPress is my home. Fam.
My hope for this workflow–and it appears to bear out–is that I can rapidly design, develop, and deploy my updates and changes. I have been using Grunt for task automation for a while now–and that required a bit of command line knowledge–but I wasn’t initially using a git workflow. I mean, it’s just me, right? Well, I found that not using a git workflow made deployment much more difficult. What do I upload? What did I change? How do I undo this change?
I’ve really just begun to do personally what I do professionally–it just makes sense to introduce efficiencies into my personal workflow when I’m so used to working this way–and I’m not really sure why it took so long.
I’ve setup a Bitbucket repo and maintain a feature branch workflow while doing development work locally with a MAMP install. I’m not currently tracking my entire WP install, only my theme, but I do my best to keep the environments similar to one another. I completely skip a staging environment for this site–I feel like it’s overkill–so it’s not a duplication of what I might do in a more important (client) setting.
I don’t really have the money for a commit-to-deploy sort of environment, so I deploy using GitFTP-Deploy to deploy changes from my ‘master’ branch.
I am still using Node/Grunt for task automation…in spite of how quickly devs seem to have moved beyond it, but whatever.
This is a bit experimental on my personal work, but something I use in my day-to-day client work
Typically we’ll track the entire site, WP install, plugins, etc.
I am introducing this process into my freelance work as well…git repo and all
For now I’m working on a minor redesign/refresh and I’ll be doing that in real time
A frontend designer (who may also go by UI developer, client-side developer, UI engineer, design engineer, frontend architect, designer/developer, prototyper, unicorn, or Bo Jackson) lives in a sort of purgatory between worlds
This is my life. I am often shoe-horned into the role of pure developer, when in reality I’m a designer that develops for the front end. Organizations that I’ve worked with in the past tend to separate the two, and this puts me in the precarious position of having to choose between them. Or those who don’t understand my skill set tend to take me with them when they need a technically minded individual to interpret and discuss a topic.
While some of this organizational separation may be justified, creating a division between designers and frontend developers is an absolutely terrible idea.
He mentions how he thinks that front end designers are particularly well-suited to bridge the divide between design and development and I couldn’t agree more. It’s a key skill set in any organization that creates and designs user interfaces.
Via Bruce I stumbled upon this interesting Hacker News discussion under the ominous title “Is web programming a series of hacks on hacks?” Thingy’s law applies, so the answer is No, but it’s a qualified No, and we need to understand what we should do in order to avoid a future Yes.
So much going on in web development that is difficult to keep track of. I often feel lost in the sea of progress.
Now that you’ve stopped laughing hysterically, I have my reasons. I found that my method of inclusion had a lot more to do with the nature of my WordPress theme than anything else. I do eliminate quite a bit of the bloat that generally accompanies a WordPress approved theme in the form of classes and the general structure that most of them use. Suffice it to say that my development methods are not going to lead me to develop massive award winning theme releases–I specialize in custom jobs that have very specific requirements, and starting from scratch to reduce bloat happens to seem like a logical move on my part. But…my digression has nothing to do with the rest of this post.
As an example, for my image posts when the primary image is hovered over I wanted to reveal an overlay with the date and title of the image. In the first iteration of this I used jQuery for the animation. That seems like an awfully bloated approach, and so I eliminated it relying instead on css3 transitions.
Of course, YMMV in regards to browser support, but for now it fits my purposes. My next goal is to modularize what I’m currently using in order to better organize my code and to hopefully eliminate some inefficiencies. I will of course be writing all about it.
But the point of all of this is that I had fallen into the trap of cramming as much awesome jQuery animation as I could into my site because I thought I needed it. It didn’t have a real purpose, though.
The fact is, I needed to understand what was going on behind the scenes in order to truly appreciate what was at work; in that way I could have found a simpler, more efficient method of accomplishing the same thing. Here’s hoping 2013 is another year of lessons learned.
Update: Just to clarify this, I see it more as a description of the fact that I am not happy with my level of knowledge rather than an indication of my total lack of it. I feel like this attitude is a motivator for me more than anything else.
It’s certainly no lie that I’ve fallen behind in my knowledge of the Latest & Greatest™ (best) practices emerging in the last year or so; staying abreast of new ideas in the world of development is without a doubt one of the toughest things to do in this profession–aside from the work itself.
What got me thinking about this was a post I read today from Mr. Noah Stokes about the advice he gave a young front end dev on how to expand his skill set.
The easy answer to this is to just do more work. Take on as many projects as you can. The more work you do, the more you’ll learn as you arrive at different problems and challenges with each project. How you solve those problems is how you build your skill set.
And that right there is the greatest challenge I face on a day to day basis. I’m simply not diving into code nearly as often as I should simply because my day job isn’t about building new things and facing new development challenges. In fact, I’m often working in some facet of design that does not require a single line of code. Instead, my job is about code maintenance, expansion, and refinement. How do I take legacy work and content and turn that into something built for modern consumption?
That in itself is a challenge, but not one that is at the bleeding edge of development work.
My goal for 2013 is to make my weakness a potential strength. Perhaps that means posting a bit of code every week exploring some problem I have. Who knows, but the bottom line is, if I want to survive, I have to improve.