After a long hiatus, I decided to start investing in my online profile again. I added some content on my homepage, re-themed my blog, and launched another push to blog more (hence this post). It seemed like a good opportunity to re-evaluate my technology stack as well. I have been hosting my homepage and my Git repositories on my Synology NAS here at the apartment, while my blog is hosted here at WordPress.com. This arrangement has been working well enough, but I’m not too keen on hosting my stuff here. The homepage hasn’t been much trouble, but hosting my Git server has been a bit of a pain. Thus began my quest to host elsewhere.
On my professional journey, I have been focusing a great deal on how to become a better developer. I have done so by exposing myself to new technologies, learning new design techniques and patterns, improving my skill set, gaining new experience, and improving my toolbox. I believe all of these are crucial to becoming a better developer. However, my recent read of The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas has opened my eyes to a number of new areas of improvement. It is easy to focus on the fun stuff like new technologies and tools, but being a professional developer also requires you to be a professional. Shocking, I know… You can get away with a lot in a small company, but I’m discovering that thriving in the complex ecosystem of a large corporation requires a different skill set. For better or worse, one’s success is tied to more than the quality of one’s code. As developers, we still have to deal with the day to day mechanics of the workplace. Mundane tasks such as replying to emails in a timely fashion, showing up to meetings on time, and meeting your commitments, no matter how small, are a big part of professionalism. While this probably seems obvious, practical experience leads me to believe that most do not take this seriously. I know many developers investing in their coding skill set, and only a few actively working to improve their professional skill set. Then again, perhaps I am simply farther behind the curve than most.
I had a chance to play a little more with LESS. This time I spent some time learning how LESS functions and Mixins work. They are very similar concepts, with a couple small differences. Both are important for maintaining the DRY principle, and are extremely powerful when coupled with the arithmetic capabilities in LESS. Let’s get to it!
I recently finished The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. I was quite impressed by the book. It isn’t so much about the art of programming, so much as the art of being a programmer. To restate, the book describes how to be a better programmer, not how to write better programs. It was a bit of diversion from some of the more technical books I have been reading lately. I was very impressed with the book. It was too much for me to absorb in the first pass. I will have to work on digesting it and come back for another pass. Next year perhaps… I thought that I would share some of the things that I took away from this read.
I have discovered one of the most infuriating problems with PowerShell. It is nearly impossible to work with complex command line applications. Microsoft refers to these as “legacy” applications. By this definition, every application that is not a PowerShell Cmdlet is “legacy”, which is rather absurd… The problem is that PowerShell insists on re-parsing all of your arguments and applying its own quoting rules. I find this behavior very helpful in the general case. However, there is no way to bypass this behavior. When you meet an application with slightly more obstinate (or perhaps obtuse is a better word…) argument parsing rules, this become an impossibly frustrating behavior.
I would like to talk a bit about another great LESS feature, nesting. For me, one of the most difficult things about working with CSS is organization. Physically locating descriptors that are logically related is next to impossible. The trivial cases are, well, trivial. But once you begin getting a few levels deep, it becomes difficult to keep things straight. They seem to silently creep away from one another within my CSS files over time. After a while, they become nearly impossible to locate. I have resorted to comment blocks and artificially splitting to multiple files, but these aren’t true solutions. This scattering is a severe detriment to refactorability. LESS enables you to nest these descriptors, grouping them together. This improves organization and refactorability. Also, this means I don’t have to repeat the leading descriptors, reinforcing the DRY principle. Take a look at this CSS example, representing a basic (and fictional) article style:
I have been experimenting with LESS lately. My current needs are very basic, so I haven’t even touched many of its more advanced features, but I am very impressed with it so far. It has been very quick to learn, easy to implement, and very handy! I love that it is able to accomplish some pretty powerful things in CSS with only minimal markup. Over the next few weeks (months?!) I’ll have several posts on the other LESS features I find most useful (such as nesting, mix-ins, and functions).
Continuing my post on learning PowerShell, I want to talk a bit about using parenthesis in PowerShell. They can be a bit confusing in PowerShell and generate some unexpected results for those coming from C#. There are two basic usages in PowerShell: grouping, and method calls. Grouping is just basic order of operations, so I don’t really see the value in discussing it further. However, method calls in PowerShell are definitely worth discussing
My development team has been reading through Clean Code by Robert C. Martin (Uncle Bob). The book is packed with good advice and excellent coding practices. In my opinion, it is required reading for anyone that is serious about being a professional developer. If you are a developer and haven’t read it, you should! It is an excellent way to hone your skills and improve the quality of your work. However, that is not what I want to focus on. Instead, I want to talk about the group exercise. We have been getting together every other week to discuss the book in chunks of 2 or 3 chapters. In between each discussion, we have a “reflective” meeting where we search for ways to apply the principles and discuss where we have already done so. I can’t speak for the other members of my team, but I think I have learned just as much from the group discussions as I have from reading the book itself. It has been a powerful tool in my own skill improvement, so I wanted to spend some time discussing why I think it has been so valuable for our team.
I recently had the opportunity to learn PowerShell. We decided to use it to manage our deployment scripts as it offers a number of huge improvements over traditional batch scripting in Windows. Overall, I am pretty impressed with it. I’m still confused as to why Microsoft insists on setting the execution policy such that you cannot execute unsigned scripts by default, but that’s a discussion for a different day. I ran into a couple of pitfalls while learning. They seem to be pretty common for developers more familiar with C-style syntax like myself, so I thought I would share.
I have long avoided the world of blogging, along with most forms of social networking. I have never wished to contribute to the epidemic of over-sharing on today’s internet. Recently, however, I have begun to think differently. As a developer, I have been helped many times by the blogs of other developers. My quest for an elusive solution to a nagging technical problem has often been paved by the experiences of others. As a professional programmer, very little (if any) of what I do is unbroken ground. This, there is much that can be gleaned from the experiences of others. While StackOverflow remains my go-to resource, developer blogs have proven to be excellent resources as well.