The rest of this post describes our journey from initially trying to implement a simple solution to improve the day-to-day lives of developers, through the technical limitations we experienced along the way, and finally arrives at the empathy for our developers we’ve gained from that experience. We’ll wrap up with a note on how Red Hat Software Collections (announced as GA in September) would’ve simplified our development process.
In my last post I talked about not being able to find a good Python editor/IDE other than vim. Nothing has really changed since then but there was another editor and IDE that was brought to my attention which I failed to point out. Let’s talk about them!
While talking with Tim Bielawa I was reminded about Emacs since it’s what Tim uses. Emacs has such amazing integration that people sometimes say it’s an operating system itself! I’ve really only ever given Emacs two real shots at being my main editor. The first time was when I was just starting to get into programming and was reading a lot about what other programmers and system administrators used. At first it seemed a lot easier than vi but I ended up running with vi/vim since, at the very least, vi seemed to always be present on every Linux/BSD box I worked with by default. The second attempt was after I promised a few Emacs users at work that I’d give it another fair shot. I said I would use Emacs when I’d normally use vim for a full week knowing that it would force me to learn more about the editor. It wasn’t easy to stop trying to use mode editing but I was able to code without feeling too contained by the editor (Note: the contained feeling was me not knowing the editor well, not Emacs itself. It was really obvious that Emacs is a powerful editor). My biggest gripes from the week long test were around needing to install emacs on systems for use (which is sort of a silly one, I admit) and I felt some of the commands were way to long. I don’t remember the last one off the top of my head but I do remember that one command had a bunch of dashes and was frustrating every time I needed to use it. I think it’s about time I try it again and see if I can overcome my hurdles trying to use it efficiently. Who knows, maybe third time’s the charm!
Cloud9 is really cool. It’s not your grandfather’s IDE by any stretch. As the name implies the application exists out in the cloud (They use Openshift). I love the idea that I can start editing code with full IDE features from any machine I’m currently occupying. I have not tried using Cloud9 with a tablet (with keyboard of course!) yet but if that works then this thing would have rockstar status in my mind. I’ve used it for a few projects for both ease of use and to test out some of the features Cloud9 boasts. Being that it is on Openshift the IDE has it’s own platform letting you install tools and dependencies. There are also some collaboration features which I have not tried out yet mainly because I’m not sure how that works when you are using Github (IE: can they push code under your name or are they restricted?). I would use Cloud9 a lot more if it wasn’t for the Internet. While Cloud9 is pretty responsive in most cases but due to some point in the network connection between “here” and “there” things slow down or stop responding for a second or two. If this was something other than coding I probably wouldn’t care that much … but this is coding. Any hiccups while editing breaks concentration and slows down progress. One other issue I noticed was the lack of preferences across ones instances. Say you have two projects in Cloud9. Each project has it’s own IDE instance. If you want to set preferences for both IDE instances you will have to open each on it’s own and set them. You can not set any kind of global default preferences for all your instances. Hopefully they will add that functionality as I’m pretty positive I’m not the only person who finds that a bit weird. Over time Cloud9 and similar IDE’s will find ways to speed up and add better preference support but until then, in my mind, Cloud9 is straddling the line between full contender and really cool tech preview to keep my eye on.
I love the Python programming language. I could spend hours explaining why it’s generally my go to language when coding something new but that’s not what I really want to touch on today. Today it’s about IDEs and editors.
IDE or editor selection is almost a cultish exercise. Developers break out into small societies around coding tools and banish those exhibiting wandering eyes towards tool lust. In some cases I’ve fallen into those patterns when I find a tool that I enjoy. It can be frustrating to have to uproot your development workflow to accommodate a new tool even when it’s obvious that after the initial learning curve the tool will make life easier. With all that said I am not stuck to any IDE or editor. I’m an IDE/editor swinger.
There are plenty of choices for Python, many of which I’ve used throughout the years. My problem is that all of those I’ve tried I always end up moving away from to one of the default editors: vim or emacs (in my case vim). For the heck of it this post is to go through the main reasons for the most recent movements back to vim.
IDEs and Editors
I used to joke that every 6 months I’d give Eclipse a try. It’s very popular in the Java programming world and has a great Python plugin called PyDev. However, Eclipse itself always feels sluggish even when I’m writing Java. Keep in mind I’m not on some old hardware which is limiting the IDE nor am I doing some corner case kind of usage. The sluggishness is not terrible either, but it’s noticeable reminding me that I’m using a very large piece of software. One of my thoughts is that if I notice the IDE/editor for anything other than a helpful feature then there is likely a problem.
NetBeans is not all that different than Eclipse in my mind. It’s a Java IDE which is extendable to other languages. Last time I tried NetBeans it was less sluggish than Eclipse. My main issue with NetBeans is I can never tell what is going one with the IDE. There was a pretty big push for first class Python support in NetBeans. I played with that IDE version for a while and, overall, liked it. Now searching python on the NetBeans site returns nothing. It seems like there are random community efforts to bring Python back into NetBeans but I want something that works well right now (no offense to any of the efforts!).
Another similar IDE is PyCharm. I have at least one fellow Python developer which swears by PyCharm and I can see why. It doesn’t seem sluggish even though it’s pretty large. It has a good feature set. But it has confusing proprietary licensing and the IDE is specific to the language. If you need to get some Ruby coding done then it’s a different JetBrains IDE and, I assume, another purchase and license agreement. That’s a bit frustrating!
Komodo IDE was one of the earlier Python IDEs I tried. I have to admit not trying it in a while, but last time I played with it I felt it was sluggish in a similar way to Eclipse. Like Eclipse it has a lot of plugins/add-ons available which is great but, then again, it’s proprietary and costs $382. Sort of a long term deal breaker right there.
The younger brother of Komodo IDE, Komodo Edit actually feels more useable to me. I believe it’s just the basic core of Komodo IDE, but that works in it’s favor. It seemed faster and kept out of my way. The initial start screen always feels clunky. However, the license is weird and is not listed on the FSF or OSI list. I guess it’s proprietary? Confusion is not a good thing.
This one kills me. Sublime Text is a fantastic editor. I really like it! The editor is very fast and has some unique features. It’s available on all three major computer platforms (Linux, Windows and OS X). The license is proprietary but is simple, understandable. I believe this may be a first. Though the fact it’s proprietary makes it a harder editor to make my default. If Sublime Text was Free Software or Open Source it would be my programming default editor.
This was a nice editor. I say was for Scribes because it looks like it is no longer actively developed. It’s a shame because it was a powerful and fast editor with an Open license. Even though it’s an older editor than Sublime Text I liked it for a lot of the same reasons. If this was still being worked on it would be my default programming editor.
PIDA was my default IDE for a while. If I was using an IDE it was likely to be PIDA. It was Open, had good plugins, fast, embedded Vim as the editor, said it loved me, etc.. However, the PIDA web site has disappeared and the last stable release was about 3 years ago. It seems like a8 may be the replacement but I’ve not had time to run with it yet.
Others To Look At
As I stated before I’d like to spend some time with a8. It looks like it’s X based only (Linux, BSD, etc..) which is fine for me since most all of my dev is on Linux. I’ve also seen a lot of talk about Ninja IDE and it looks promising though I’m generally not a fan of specific language IDEs since I am not always using the same language.
What Do You Use?
Seriously. If you are doing Python development regularly what are you using and why? What features have you found to be amazing and which ones are overrated marketing dribble? Am I the only guy who continues to go back to vim in this day and age?
I’ve gotten a number of homebrews under my belt. One way I decided to experiment was to make the same beer in terms of malt and process but change the hops. While it’s helpful to read the hop profiles that people have put together the only real way to figure out how I perceive the profiles is to dive in and and see what happens. The basic idea is that I’d be able to pick out differences in how well a hop bitters, flavors and adds aroma when it comes to my taste buds. So far I’ve only done two of these experiments but the results were enlightening!
1. The same DME and steeping grains (if used) must be used for all brews in the experiment
2. A standard IBU must defined to hit. I decided on 40 IBU
3. More than two hop additions must happen during the boil. One addition must be at 15 minutes or under
4. Dry hopping will always be 1 week and will be 1 oz
5. Only 1 variety of hops may be used
Experiment 1: Chinook
My first brew for the experiment was all Chinook. I read a bit about the hop and noted the conventional wisdom was that a little goes a long way. What better hop to try than one that most people think can be overdone! The result of a 40 IBU Pale Ale (closing in on IPA) was a beer that was complex enough to stand on it’s own. The bittering was strong and set up for the flavors to follow. The flavoring brought with it pine, earthy notes and a little orange and grapefruit like citrus. One person described it as “orange rind like”. Aroma is where chinook fell down. Dry hopping did not produce the strong aromas that I would have expected from such a potent hop. While present, the aroma was light. All in all this was both a success for the experiment as well as my taste buds.
Experiment 2: Citra
Citra is a very popular hop addition which is spoken of fondly by many homebrewers and avid IPA lovers. As the name implies it has a strong citrus side but also includes a lot of tropical fruit like characteristics. Citra also produced a good, strong bittering. This I expected based on the Chinook results. as both varieties have high alpha acids. However the flavoring and aroma differences were quite shocking. The flavor is much more citrusy than chinook. This itself was not shocking but what did get me was the simplistic nature of the hop when compared with chinook. I found myself highly enjoying the pint to start and, by the time I was 7/8′s through the glass being bored. The complexity that chinook has is not present with citra but more on this in a moment. The aroma that citra gives is strong and inviting. A combination of sharp citrus notes and smooth tropical fruits. Using this in a dry hop mixture seems like it would produce some great things! Unlike chinook it seemed like citra needs mixing to get the complexity that my taste buds want. The flavor and aroma was pretty much the same (and the bittering was bittering as one expects). So by the time the glass was nearing empty I was bored with citra. I think citra shines best when used with other hops, not as a single hop.
I didn’t expect the two to be that different in their usage. I figured there would be differences in flavor and aroma but not as much in the complexity ability. Both produced good beers but, of the two, the chinook based on is easier to drink more than one while the citra based beer is good for a glass (and fades through the glass). In other words the experiment has already proven useful to me and I’m only two hops into it. I’m eager to find out how other hops fit into the puzzle!
It’s true. Or at least I believe it is. I’ve been using Untappd long enough to be able to see some basic trends in what I find to be quality beer. The overwhelming majority is craft beer (big craft, micro, nano, gypsy, brewpub, etc..) but, to my surprise, there were some macros which I legitimately enjoyed as well. The top three macros were:
Hacker-Pschorr Hefe Weisse Natürtrub
I didn’t know this was a macro brewery else I honestly would have passed on it. I’m glad I didn’t know as it’s one of my favorite hefe beers. It’s got nice, strong banana esters, good feel and easy to drink.
Probably the most obvious one and on many lists. It’s not my favorite dry stout ever but it is tasty on draft. In a can or bottle I will probably pass unless the list is all macros. I can never seem to shake that extra bitter taste that accompanies bottled Guinness.
Murphy’s Irish Stout
Also done by a macro. I’ve never seen it on tap but for a dry stout in a can it’s good. It does have a thinner mouth feel that can turn some away but, for me, it works well.
While it’s nothing earth shattering it does tell me to judge less on the maker and more on the brew. It’s possible for macro including MBC to release a well crafted beer. But probably less likely. I don’t believe that macro beers will shoot up on my list any time soon, but I welcome the few that hit the spot.
My first homebrew was an experience that taught me a lot but had poor taste results. My second attempt, an American IPA, turned out much, much better. As one would expect my IPA was full of hoppy goodness. Since I’m still new I decided to use a kit from the fine folks at American Brewmaster. The recipe I used called for Summit, Centennial, Cascade and Amarillo. I decided to add Columbus for a short dry hop as a way to make the recipe my own.
After brewing I kept in primary for 10 days and then racked into a secondary for dry hoping. While I probably didn’t need to move to secondary to dry hop I decided it was worth doing due to my worry about keeping the beer on the trub too long (I know now it takes a lot longer than a few weeks to cause a problem ..). Next I dry hopped in secondary for 4 days. Why four days? Mainly because I really wanted to find out if my brew worked out this time and couldn’t wait. So after four days I racked to my bottle bucket with my carb sugar, filled the bottles and capped.
After 1 week of bottle conditioning I decided to see how well carbonation was coming along. This is what I saw after an aggressive pour.
I was happily shocked. I was not expecting so much carbonation so quickly! My first brew never got half that carb’d! Like my first try the aroma was amazing but I knew the kicker would come with a first taste. So I took a few bottles and threw them in the fridge for tasting later.
I pulled the bottle and shared it for a testing. Both of us agreed it was quite good. It cleared up a bit compared to the above picture but it still needed some time to settle. Here is my review (of my own beer so take it with a grain of salt…).
Slight pine with earthy/herbal notes. Nothing overpowering. Reminds me more of a pale ale.
Nice and bitter but balanced well with a malty backbone. There is also a very slight ester profile as well which surprisingly works in the brews favor adding a bit of fruit complexity. The hop profile is hard for me to really explain but the closest comercial beer I can equate the bitterness portion of flavor with would be Sierra Nevada‘s Torpedo. As the ale warmed up the bitterness came through even more. Even nearing room temperature the beer still was tasty!
Medium mouthfeel with consistant carbonation. Possibly a little creamier than should be due to things still not being settled.
Happily surprised. For me this is a pretty unique beer (though is probably pretty common in homebrew circles). My rating is 4/5 stars.
I’ve gotten two pieces of feed back so far on my first successful homebrew. The first was simply “Oh, that’s good!” during the shared tasting. The other was an unsolicited text from a friend when he popped the cap and gave it a whirl: “Your beer is excellent.” That feedback made me feel pretty good.
I’ve since brewed an Abbey Dubbel and a single hop American Pale Ale of my own design. Both are in primary. If both of these come through successfully I’ll feel pretty confident in my process.