What We’ve Been Working on at Clevyr Labs

Aaron Krauss talks about what his team has been working on at Clevyr Labs. Aaron is a developer at Clevyr and Clevyr Labs where he builds data-driven applications and games in JavaScript, .NET, Ruby, Shell, and anything else awesome.

Talk: Getting Started with F#

F# is a functional programming language that runs within the .NET framework. In this talk, we’ll learn what it means to be a functional language and how F# ties this together with the rest of the .NET framework. Everything will be live-coded, so you’ll get to see exactly how things work as they’re coded out. This talk is very beginner friendly to both functional and .NET development alike – so come join us!

My Experience as a Contract Developer while being Employed

Last Fall of 2016, I had the experience of taking on a contract web development project while I was actively working as a full-time W2 employee, and I want to share with you my experience through all of it. Whether you’re considering doing something like this yourself, or you’re a seasoned developer who’s already worked many contract side projects – I hope this helps to show you another perspective. This was my first big contract job that I’ve been paid for on the side, and I learned a lot from it – especially that the lifestyle of combining full-time employment with outside work just wasn’t a good fit for me. But I’m getting ahead of myself, we’ll get to all that; for now, I just want to walk you through what the project was like, how it all got started, development, design updates, and my mentality through it all. Let’s get to it.

Phase 1: Project Setup

It was back in August of 2016 that I was contacted by my old boss at a previous employer to see if I’d be interested in building a web site for one of their clients. The project would be similar to every other project I did while with this previous employer, so I knew I already had the skills to take it on; in case you’re curious, the project was a fully custom-built site using Craft CMS. It would be about 80% HTML, CSS, and front-end JavaScript – and 20% configuration on the backend for the CMS. The thought of making a little extra money on the side excited me, and I trusted this client since I already had a relationship with them (I worked there for multiple years). So far, everything seemed pretty awesome: I knew how to do it, and I felt like I didn’t have to worry about any issues over actually getting paid. I checked with my current employer to verify that they were cool with it, as well as my girlfriend Layla (since I’d be spending evening and weekend hours on it) – and everybody encouraged me to take it on. Things were looking as perfect as could be.

Within a week, I had lunch with the client (my old boss) as well as the designer on the project, and I got the design comps for the website so I could start building things. After spending a couple hours setting up my work environment to run this CMS, I was ready to rock and roll.

I was told that they’d love to have a staging site up in about a month (mid-September), and were planning to take the site live the first week of October. So far, this project was continuing on its perfect streak, because I felt really good about hitting those deadlines. I won’t disclose my rate, but suffice it to say that I kept it low compared to what I’ve heard other developers charge – simply because this was my first contract job. I wasn’t too concerned about getting burned financially; if it happened, then it happened, but I felt fair about my estimated hours. I quoted 50 hours for the project in total: 40 hours of development, and 10 hours of updating based on the client’s needs. I charged a lump sum amount to be paid after the project was done, so if I made it under my quoted hours, then I would have technicaly been paid “extra,” but if I went over, then I wouldn’t get paid for that extra time.

Phase 2: Development

I gave myself 40 hours to develop the site and get it pushed up to staging, and everything honestly went really smoothly and methodically in this phase. I built a home page and styled it, built the navigation, tied all of that to the CMS, and then started working on sub page components. I spent about 2-3 hours every evening on this project for a little over a week, and I got a lot done pretty quickly. My favorite feeling was that while I was early in my hours (< 15), I truly felt like I could spend the time to architect the site and the CMS in a way that made me proud. I built accessibility features, semantic HTML, CSS that followed BEM and SMACSS, etc. I was really happy with it.

There were a few times that I needed to communicate with the client to ask for clarification on design, but that always went well. We communicated entirely through Slack (we were both a part of a local developer community Slack group). After I hit about 20 hours, things were looking good; I had a lot done, but still had a good chunk more to build. It was about this time that the project started slowly wearing on me. I started thinking, “I’m spending these evening hours working, when I could be enjoying them with my family, writing blog posts, playing video games, or just relaxing.” I kept pressing on, but I kept coming back to the thought that these hours I was spending on this contract project weren’t like normal hours I’d spend during a workday. They were prime hours – hours that I only get perhaps 4-5 of a day (time at home after work, before bed, and not spent at the gym). These are my most valuable hours of the day, and this was the only time of day that I could really do things for me. I really started thinking that this might not be how I wanted to spend my free time – or at the very least, I might want to do this very sparingly.

I want to reiterate that the project itself had nothing to do with how I was feeling. The project was 100% perfect, and I truly enjoyed what I was building as well as the tools I was using to build it. Everything was great from that standpoint. It was just the lifestyle that was getting to me.

Regardless of my thoughts, I bulleted through the development phase of this project and got up a staging site right at 36 hours. I came in 4 hours under my quoted development time, which was awesome. That gave me 14 hours to handle any updates from the client – and from my experience being previously employed with this client, that was more than enough. Metaphorically, it seemed like I just rounded 3rd base and was sprinting to home! Or so I thought.

Phase 3: Updates from the Client

It was this phase that really broke my desire to ever want to do contract work again while being employed. I took about a week off after I got the staging site up, which was really nice. I enjoyed my free time relaxing during that week – but there was always this reminder that the project wasn’t done yet, which was kind of like a constant weight on my shoulders. After a few days, I got word from the client that they were really happy and had some updates (which I was expecting), and they shared them to me via a Google doc. When I first saw the updates, it was much more than I was expecting – but nothing I couldn’t handle. I spent about 5-6 hours on that round of updates, which was perfectly fine because I was still under my quoted hours (currently at 42 out of 50 hours).

After I finished those updates, I should have been done, right? Wrong. That was only the first wave of updates in what seemed to be an endless sea of updates for a good month. Within a few days, I got new updates to work on from the client, and when I’d finish those, I would get more soon after. Some updates were small, but some took several hours to work on. For about the whole month of September, I was pretty unhappy working on this project. It turned from something that I enjoyed building to something that I just wanted to be done. It was this constant cycle of thinking that these updates would be the last ones, and there always seemed to be more after that – and that right there wore me out more than anything.

It became this running meme in my household that whenever I’d plan to have some free time, I would always spend it making updates to this project. Literally all of my free time was eaten up. I’d occasionally think things like “I just got the Witcher 3 for my birthday, maybe I’ll play that?” – soon followed by the reminder that I still needed to work on this project. Layla was super supportive throughout this whole process and kept helping me to focus on the end goal – but I know that even she was ready for me to be done with this project.

Every update I made was within the scope of the project, so please don’t think that the client was being too demanding. My job was to give them a perfect site, and I absolutely wanted to follow through on that. After everything was said and done, I spent over 26 hours on updates. I had only planned to spend 10 hours in this phase initially – and I even thought that was a lot. I’d never spent this amount of time on client updates before – but every project has the potential to be different, and this one certainly was in that regard.

Phase 4: Done!

Early- to mid-October (about 2 months after I got the contract), the site finally went live, and there really weren’t any updates after that. I finally started feeling relieved, and like I could truly start spending my free time like how I used to.

All in all, I spent 62.5 hours on this project, and I quoted a price for 50 hours. That means I spent more than 20% additional time on this project than what I was getting paid for, so I politely explained the situation to the client and asked if I could increase my payment by a set amount to get closer to the time I actually spent on the project.

The client was really awesome about my request, and granted me the extra money. This was absolutely something they didn’t have to do – and I was aware of that, since we had an agreement before I started – and I was super thankful about it. I’m glad I asked, and if you’re in a similar situation, then I encourage you to do the same. The worst that can happen is that you’re told “No.”

I soon sent an invoice to the client, and they paid me within a month. This project now had officially been put to rest; I was happy, my client was happy, and their client was happy (the one who the site was actually built for).

My Overall Thoughts

I want to make it absolutely clear that this project was as perfect as it could possibly get as far as contract work goes. My initial quoted price was immediately accepted (and increased when I asked!); I used to work with this client, and thus trusted them to not swindle me out of getting paid, or treat me poorly; I was very confident in my ability to perform this contract, and there really weren’t any unknowns; the deadline was a ways away, so I had more than enough time to build the project; and lastly, it truly was a fun site to build.

It sounds silly to say, but this experience was seriously valuable to me because I know now without a doubt that I hate contract work. I do a pretty good job of leaving my full-time job stress at work, and am able to really enjoy my free time otherwise – but something about contract work just continuously stressed me out during the 2 month period that I was working on it. That’s definitely a personality trait of mine – and I completely understand that everyone’s different in this way. I just wasn’t very good with time management, I suppose. I think it’s because with my full-time job, I know that I’ll be there 40 hours every single week to get done what I need to, and that’s a lot of time. With contract work, I really don’t have any clue as to how much time I’d have to dedicate to it during any given week – and I think that stressed me out a lot. I would often wait until Layla fell asleep to work to work on it, because I hated the idea of taking time away that we could be spending together – but that meant that I’d be working late into the night when I’d rather be sleeping, and normally I’d only work a couple hours a night. You can only do so much in that small time frame, and the next day I’d be back to stressing out about when I’d have time to work on it again. I really struggled with that. I’m sure a seasoned pro at this would dedicate set times every week to work on contract projects – but I just had no idea what times I’d consistently be free.

Here’s my advice to you: if you’re thinking of doing contract work while being fully employed, be 100% transparent about it. Inform your current employer, your family, your friends – anyone important in your life. It’s much better for all of your relationships if you’re open about it. If your employer isn’t cool with it and you can’t convince them otherwise, then it’s best to just say no to contract work rather than go behind their back. Trust me. That same advice goes for your family too. If it’s going to cause any problems at all, it’s not worth it.

I hope my experience working as a contract developer while being employed as a full-time developer helped you in some way. It only took one contract job to show me that this isn’t the lifestyle I want to lead – but if you’re able to handle it just fine, then I encourage you to keep it up! Everyone’s different, and that’s something I really learned through all this. I found that I truly value my spare time much more than any hourly rate could provide me, and thus I decided to hang up my contract developer hat.

Tax Season Update: After filing 2016 taxes, nearly half of the total amount of money I made from this project was taken away. Yikes! I was expecting 30-35%, sure – but I was unaware of the additional self-employment taxes that added to it. Definitely something to keep in mind if you’re planning to do contract work!


P.S. If you made it this far, then you deserve to see the actual project I’m talking about in this post. I hope you enjoy it! I’m really proud of it.

Presenting: Guernsey

My Interviews with Amazon

Last Fall in 2015, I interviewed with Amazon Web Services for a senior web developer position and was eventually offered a job with one of the AWS teams. Interviewing with a massive tech firm like Amazon was a significantly different experience than with any other company I’ve interviewed with, and I want to talk about how it all went down. How the interviews were structured, what all was discussed, what questions were asked – all the way down to getting flown out to onsite interviews and eventually getting the offer. As I was going through the interview process, I read posts on several forums by people who went through the same thing – and they were helpful, but they never got very deep. Not much of it applied to me, and it would have really helped me to feel more comfortable throughout the process if I could have found a true documented experience by someone who had gone through this before. This is my chance to make that happen for you, the future developer interviewing at a global tech firm. Spoiler alert – I did not accept the position, even after the entire interview process. We’ll get to why I made that decision, but first let’s start from the top.

Interview Structure

You can break my particular interview process up into a few segments – and that’s how I’m going to talk about them:

  • Phase 1 – Getting Recruited
  • Phase 2 – First Phone Interview
  • Phase 3 – Second Phone Interview
  • Phase 4 – Onsite Interviews in Seattle, WA
  • Phase 5 – The Offer

As far as my research went, this is more or less the same process that most developers went through who interviewed with Amazon, Microsoft, Google, etc. However, I read a few stories of developers having 3 phone interviews instead of 2, so your mileage may vary. I’ve bored you with enough of this meta-information – let’s get to the meat of the process.

Phase 1 – Getting Recruited

As a developer, I get hit up a lot by tech recruiters either through email or LinkedIn, and honestly I tend to ignore most of them or – if the recruiter sent a half-way decent message – respond politely, declining their request. However, one day in August of 2015, I received a message by a recruiter – but not a normal 3rd-party tech recruiter like I normally see. This was a recruiter working at Amazon Web Services, specifically searching for a Senior Web Developer with one of the AWS teams. From the very beginning, I took it very lightly. I responded saying that working for Amazon would be awesome, but for me and Layla to move up to Seattle would require a 170-200k salary. I assumed this recruiter would take a look at that number, scoff, and politely end our conversation – but she affirmed that they could work with that, and asked if I wanted to set up a phone interview.

I was pretty shocked – but I told her I’d bite. I’ll play along for now. After all, how many times do you get to interview with one of the most influential companies in the world?

Over the next week, I emailed with this recruiter and her hiring manager to complete some basic paperwork and to schedule a date and time for my first phone interview with AWS.

Phase 2 – First Phone Interview

My first phone interview was scheduled at an exact time (2pm) with the manager of the service that I was interviewing for – so basically my intended future boss. I remember I spent the whole day looking up common interview questions for programming, and watching a lengthy video series over data structures so that I knew the time and space complexity differences over iterating between arrays, hashes, binary trees, etc. A few minutes after 2pm on a Friday, I received a call from the manager – we’ll call him Bob (not his real name). All in all, the phone interview lasted about 1 hour and 10 minutes – and it really wasn’t technical at all. No coding, no super-deep programming questions. Initially, the phone call seemed a little bit “bureaucratic” in the sense that I had to verify that I was expecting this call and made sure I had allotted a full hour to speak – but it quickly became very relaxed.

Bob started off with just asking about my general skill-set, and told me a little bit about what the position entailed. After about 20 minutes, we segued into other questions. He asked me if I could explain a single-page app, what MVC was, and he asked me a time when I disagreed with my manager. I hate those types of situational questions – but it wasn’t too bad. We spent about 20 minutes talking about that one question. After that, we just made some small talk about weather, what Bob does, the fact that it was Friday and he was taking it easy, etc. The last 20 minutes were really chill, just 2 people talking. Neither of us were bothered by the fact that the interview had gone about 10 minutes late.

Before we got off the phone, I asked for Bob’s email address (with the intention of sending a thank you email later in the day). I was told that I would hear back within the next week about whether I made it to the next interview. This part was pretty crazy to me, because it wasn’t even a full hour before I heard back from the Amazon hiring manager saying that I had passed the interview and they wanted to schedule another phone interview with someone else to assess my coding abilities. This next interview was scheduled for the following Thursday, this time at 3pm.

Phase 3 – Second Phone Interview

Unlike the first phone interview where I had no idea what it was going to be like, I knew ahead of time that this interview was going to involve me coding for an hour. I was given a link for a service called CollabEdit where I would code inside of a text area and the interviewer – let’s call him Jim – would be able to see in real-time what I was coding.

Jim called promptly at 3pm, and told me a little bit about himself. He was also a manager, but in no way related to Bob or Bob’s team. Jim was someone who I would never work with, and was strictly there to assess my coding skills. He told me he had 4-5 questions for us to get through, but if we only got through a few, then that would be fine. The emphasis was on him assessing me, and not necessarily completing the questions.

For about 45 minutes, I coded with him on the phone. I had a bluetooth headset and mic while I was coding, which I highly recommend anyone else do. I couldn’t have done this with my phone held up to my ear by my shoulder. We spent the entire 45 minutes on one question. Just one. And it was about client-side javascript. The single question was about how would I find all HTML elements on a page by class. Within the first line, I started with a simple jQuery selector – which he said worked. But then he slowly started giving me constraints. How would you do this without jQuery? How would you do this with multiple classes? Can you use a wildcard selector? etc. We spent the whole time on that one question; it was actually pretty fun – we both got really into it. My biggest tip here for anyone in this same position is to talk about what you’re thinking. Jim’s just a man on the phone who can see what I’m coding – but he doesn’t know what’s going on inside my head, so I need to help him with that as much as I can.

Towards the end of the hour, Jim stopped the coding session and asked if I had any questions for him. We then talked for a minute, and he told me something similar to what Bob said – that I would hear back within the next week, but this time, instead of another code interview, the next step would be an onsite interview. He did tell me that he’d had good interviews and bad interviews in the past, and he felt good about this one. This interview was on a Thursday, and I heard back the following Tuesday evening that I had passed onto the next (final) round of interviews.

I was going to Seattle.

Phase 4 – Onsite Interviews in Seattle

I got the email that I had made it to the next stage of interviews, and was asked what dates would be best for me to fly to Seattle for the interviews. This email exchange took place on September 9, and the dates matched up for me to interview in Seattle on October 12. Once the date was set, I was given the information of an Amazon travel agent (run by another company) to call and schedule airline times and whether I was staying 1 or 2 nights. My interview was on a Monday, and I was offered to fly up on Saturday and stay two nights – but I opted to fly up on that Sunday, and then fly right back to OKC directly after my interviews on the Monday. Just a 1 night stay. This is all paid for by Amazon, by the way. I didn’t have to give a credit card number at any point in time.

Once October 11th came, I flew to Seattle and stayed at Hotel Ändra in downtown Seattle. To get around, Amazon told me I could take a cab, Uber, public transportation – anything, and they would reimburse me up to $100/day for food and travel combined. I took the Light Rail directly from the airport to downtown Seattle for $3. Talk about a deal. For dinner, I just got room service. Eating dinner out alone is just … lonely.

My interviews were scheduled to start at 9:45 am on Monday, and were to finish at 2pm. I woke up early, got breakfast by the sea, and explored Pike Place while it was opening up for the day. Definitely a neat experience. From there, I just walked to the interview building.

Amazon encouraged me to dress casually, but I still dressed business-casual (button up, dress pants, no tie). Throughout the day there were 5 back-to-back interviews, each one-on-one. All coding was done on a white board. No electronics involved at all (except for the interviewer taking notes). Here’s the breakdown of my interviews:

  • Initial interview with a team member I’d be working with. 50% discussion, 50% coding.
  • 2nd interview with a developer on another team. 20% discusion, 80% coding. This coding session involved more “traditional” coding interview questions. The main question was about how to build a circularly linked list, and how would I add a method to delete a node and have the linked list still be circular. I started answering this in C, but after my knowledge failed me, I just moved to ruby, which was significantly easier for me. The interviewer was cool with it, even though he didn’t know ruby.
  • 3rd interview with a developer on another team – strictly to assess my personal skills. These were the “fun” situational questions (mixed in with some personal experience questions). 100% discussion, no coding.
  • 4th interview with Bob – the manager of the team. This was over lunch which he paid for. It was mostly casual talking, but he asked me some technical questions as we were eating.
  • 5th interview with a developer on another team. 20% discussion, 80% coding. This was a very front-end oriented interview. All code involved web development topics, HTML, CSS, and Javascript. One question was how an interaction with a JSON API is different from standard HTML, leading up to how single page apps work – so I basically drew a simple diagram of the request process for a single page app. The main coding question was how would you build a slider (like the ones you see on every page). I stumbled on this at first – as it seemed like a crazy interview question, but I took it one step at a time, i.e. a slider is just a wrapper element with child elements. The CSS should just position them absolutely next to one another. Clicking arrows should just issue JS to shift positions of those divs.

After my final interview, I had just over 2 hours until my plane took off (I wanted to get back home as early as possible). I booked it to the Light Rail station, spent another $3 to get to the airport, hustled through security and made it minutes before my boarding time.

If you go through an interview process like this, here’s a big note: don’t bring checked luggage. You’re staying for a very short time, try to keep everything carry-on. Checked luggage will just be a pain to deal with.

Phase 5 – The Offer

Back in OKC, it was either the next day or the day after that I got a call from Amazon’s HR department. I was told that Bob liked me and they had an offer for me. I won’t get too specific, but it was in the low 6 figures (plus a bonus) – definitely not the 170-200k the initial recruiter told me they could do. Restricted stock units (RSUs) were a part of their overall benefits, and made up about 2k of salary for the first year. They made up a little more after the second year, and would have maximized by year 4. In total, it probably would add up to 40k of stock after 4 years – which isn’t a petty amount. Regardless of salary, I was honestly pretty shocked that I had gotten an offer, and told the HR person that I would get back to them within a week after I discussed this with my family.

This is probably terrible to say, but everything was a game to me up until this point. I never in a million years thought I could get picked up by Amazon – but here it was, the opportunity. We spent that whole weekend deciding what we wanted to do – but in the end, we made the decision not to take the offer.

Relocation cost wasn’t an issue – Amazon pays for all of that, and goes above and beyond to make sure you assimilate to Seattle well. The other benefits that Amazon offered were pretty stellar too, but there were two big reasons holding us back:

Cost of living. Here in OKC, we have super cheap cost of living. In Seattle, we would be paying twice our current house payment for a mid-level downtown one-bedroom apartment, and 2.5 – 3 times our house payment for a two-bedroom. Houses were pretty much out of the question – anything comparable to what we had here that was near downtown Seattle was anywhere from 600k – over 1 million dollars. Sure – the offer I got from Amazon was twice what I made here in OKC at the time, but that was still just too much for us.

Family. This was the big deal. We never really thought about leaving family – until we were forced to. We just couldn’t do it. We have parents, friends, siblings, and nieces all within a few miles that we see just about every week, and we just didn’t want to give that up.

It was difficult, and I did wonder for a few days or so if we had made the right choice – but I’m positive we made the right decision to deny the offer. I explained the whole situation to the HR person I was working with, and he was very kind about it and congratulated me on getting the offer nonetheless. For me, this was truly the opportunity of a lifetime, and I’m so thankful that Amazon was awesome enough to let me have it.

Final Thoughts

I’m sure some of you out there would kill me for not taking the opportunity to work at Amazon – but I promise you, we made the right choice for us. We belong here for now, and going through this process showed me that big time. Plus, with the OKC developer community really growing within the last couple of years, I’m not sure I ever want to leave now. We’re rooted, and I’m happy about that.

Thanks for all of this, Amazon.

The 3 Rules of Dev Blogging

This post covers a short lightning talk I gave at OKC.js this past Tuesday, March 15, 2016 over the 3 Rules of Dev Blogging. The format’s a little bit different (okay – very different) from my normal blog posts – but that’s because I wrote this post to be the actual slides for my talk. Happy reading if you can follow along with my short notes!

 

Rule 0: Pick a Platform

  • WordPress
  • Ghost.js
  • Medium
  • Many others

 

Rule 1: Write about 2 things

  1. Things you know really well
    1. Tutorials, Explanations of Concepts, etc.
  2. Things you don’t know at all

 

Rule 2: Schedule Your Posts

Write your blog posts in advance, and schedule them.

Figure out what release schedule works for you. Every month? Every other month?

Start with a longer release schedule

 

Rule 3: Market Yourself

Blogging is more fun when you know people are reading what you write

Inner Circle

  • Facebook
  • Twitter
  • LinkedIn

Outer Circle

  • Reddit
  • Google+ Communities
  • Hacker News

 

The End

My Blog: https://thesocietea.org/blog

Twitter: @thecodeboss

 

3-rules-of-dev-blogging

 

Launched: Labs and My Beer Adventure

Two smaller personal projects that I’ve been working on have officially launched, and I couldn’t be more excited: Labs and My Beer Adventure. Here’s a description of what they both are and some of the tech choices I made behind them.

Labs

Labs is a small project of mine that I built in order to showcase some of the smaller projects that I do on my own that aren’t necessarily big enough to promote as an entire site (or even their own GitHub repo). In fact, the entire labs project is a single GitHub repo, and I intend to keep it that way. The projects that I choose to be a part of labs are geared to be more visual demos – things that you could navigate to a URL and see an actual representation of what I’ve been working on, without having to install anything. For the most part, this limits me to projects that are HTML, CSS, and Javascript, but I’ve even got a project in Go up there that I’m running as a web server to be a wiki that’s tied to a MongoDB database.

The site is fully responsive, and while I designed this main site completely from scratch, I didn’t want to spend as much time building my labs site since I wanted it specifically to showcase other projects. I dug around for a bit, and came across a neat site called HTML5 Up that has several clean, well-built site templates that are completely free to use. The only small caveat is that you have to give attribution somewhere to its creator, @n33co, but if you’d rather not give attribution, then you can purchase a very inexpensive license to get instant access to all of his amazing templates completely attribution-free. I want the developer of HTML5 Up to be known by everyone, so I’m proud to give credit where credit is due.

Check out my labs here: http://labs.thesocietea.org


My Beer Adventure

Since around my 21st birthday, I’ve been a fan of beer and the history of beer styles, especially with the craft beer movement going on. However, it’s been a long time since I really spent any time towards learning more about beer styles, beer history, beer brewing methodology, etc., and I also haven’t been drinking as many unique beers as I’ve been wanting to. So, I made a New Year’s Resolution for 2015 to drink a new beer every single week – a resolution which I have happily abided by so far. I’ve been documenting my beer selections via my Instagram account, and it was brought up by one of my developer buddies that I should start actually blogging about my choices.

I liked this idea because not only would it be easier to share with everyone my beer choices through 2015, but I would have a dedicated spot where I could share my experiences with each beer besides Instagram. Similar to my labs project though, since my main purpose for this blog would be to share content, I didn’t want to spend a whole lot of time on design. This beer blog could even be simpler than my labs project too, since all I needed was a blog and nothing fancy. My main site runs on WordPress (see why I made that choice), which has been an excellent CMS for all my various content, but I didn’t need anything that heavy for this blog. Additionally, I didn’t want to tie my beer blog directly into my personal site since I’m trying to keep my main site pretty developer-centric.

There are a bunch of neat blogging options out there that aren’t WordPress, or even PHP based at all. Jekyll, Octopress, Middleman, etc., but I wanted to try a newer option that’s been gaining a lot of traction lately … Ghost.

Ghost is a node.js based blogging engine that has gotten over 3,000 forks on GitHub – enough to pretty much verify that it remains a stable blogging option. Their slogan is “Just a blogging platform,” which is exactly what it is – a blog. Nothing more. You write your posts using Markdown, you can download and use different themes, and you can manage multiple users on a single install – but that’s the extent of Ghost’s core. Need static pages? If you can build them in Markdown, then you can use Ghost, but anything else and you’re better off with another platform.

Ghost can be installed and used by either cloning the base repo, or installing it as a node module using npm. It’s insanely easy to get going, and because it uses sqlite which is a file-based DB, it’s so easy to sync deployments across different environments. Ghost is always free for developers, but even if you’re not a coder, they provide hosting options that handle the install for you (you just need to shell some monthly bucks for that nicety). You can check out the GitHup repo for My Beer Adventure which shows Ghost installed as an npm module.

Check out My Beer Adventure blog here: http://beer.thesocietea.org


Final Words

As far as deployment goes, both of these new projects are deployed side-by-side with my main site on my $5/month Digital Ocean VPS, which has easily been the best tech purchase I’ve made so far. Labs is strictly a client-side project, so all it’s using in order to run is the nginx web server, but with My Beer Adventure being a node project, I’m running it using nginx and the forever npm package which runs the node process as a daemon.

Don’t worry, the next post will return to our Rails API series – I just wanted to promote these small projects and discuss the tech behind them!

Software Licensing: DRM vs GPL

This post is based off of a paper I wrote in one of my Computer Science classes during college, and has been the only college work I have ever referenced after I graduated. Sounds like an awesome expenditure of money right there, but I can’t complain. So, let’s begin:

Software licensing is a contract of agreement between a software publisher and the end-user, basically preventing any type of legal infringement of the software such as modifying code, duplicating discs, and implementing multiple installations. Some sort of software licensing is seen on virtually every application that people use today, and although the practice of software licensing does include restrictions on the user, the ideas behind it are usually moral. Software licensing schemes are used frequently to label different types of rights and restrictions for software. The two types of licensing schemes that we’ll be talking about here include Digital Rights Management (DRM) and the GNU General Public License (GPL), both of which are very prominent.

What is Software Licensing?

The practice of software licensing involves a lot of different ideas, where placing restrictions is just one of them. It serves as sort of a disclaimer to the user, often times releasing the publisher from any or all liability for any unseen events or circumstances that may occur with use of the product – these are often discussed in the End User License Agreement (EULA), or just a general disclaimer if it is a web project.

Software licensing can be divided into two different categories: Proprietary and Open Source. Proprietary software licensing is described as software that is exclusively owned by the publisher, and who can therefore determine the overall rights of a user and how software use should be restricted. Open Source software licensing instills ownership of the software within the user, who is therefore guaranteed unlimited rights to software use so long as it remains under the rights granted by copyright law. The main difference between these two licensing schemes is the effect that they have on the user?s overall rights with the software.

DRM

Digital Rights Management provides good examples of a proprietary software licensing. DRM refers to access-control technologies used by software publishers to limit the usage of digital media; DRM itself is not an actual software license, but it includes the class of technologies that are most commonly associated with controlling the use of digital content and devices after sale. DRM has gone through two generations, with the first generation solely focusing on preventing the pirating of copy-written software works. Second-generation DRM is typically what we see today, and instead of putting a heavy focus on trying to stop pirated works, it’s more geared towards controlling the execution, viewing, copying, printing, and altering of works or devices. Although it is meant to provide restrictions for unlawful purposes, DRM often goes beyond its necessary boundaries. The use of DRM is pretty controversial, but several publishers argue that it’s necessary in order to prevent duplication of software and other illegal violations of intellectual property. Several complaints have been held about DRM violating users? personal rights, and many believe it to be a disaster to innovation, fair use, and competition. Today, the evolution of DRM in video games specifically can be seen in the new trend of always-on DRM, where gamers must maintain an internet connection even just to play single player (Diablo III, SimCity, among others are all culprits).

Congress, however, strongly backs DRM and continues pushing to create laws which requires DRM to be increasingly more present in new works (anyone remember SOPA and PIPA?). This type of legislation would give original publishers more power to restrict a user?s ability, and could easily step into the realm of breaching freedom of speech and innovation. Opponents of DRM often make fun of it by calling it ?Digital Restrictions Management,? as they claim there are hardly any rights involved.

GPL

The GNU General Public License (GPL) is the most widely used free software license which grants virtually unlimited rights to the user. The code of an open source program may be modified to create a new project for instance, a condition that proprietary ownership would never allow, and it must merely include somewhere in the project that it was ?based off? the original software. Developers that use the GNU GPL protect the user?s rights by asserting copyright on the software, and by offering the user this license and giving legal permission to copy, distribute and/or modify it. GPL is a copylefted licensing scheme, meaning that developers who do build off of an existing product that has a GPL license to create a new product are required to use the same licensing terms; this is in contrast to other popular free software licenses such as the BSD or MIT licenses, which are not copylefted.

As is common in free software licenses, there is no warranty under the GPL; this may seem like a big downfall, but it ultimately protects the publisher from unseen errors and circumstances in newer or modified versions of the software. The GPL refuses the use of patents, which many claim restrict development and create unnecessary fees for the use of software.

Final Thoughts

Overall, the practice of software licensing aims to be a pretty moral concept, even for proprietary licenses – after all, someone should get credit for writing software, even if it does instill restrictions upon the user. If software licensing were not enforced by publishers, profits could shift dramatically, which ruins the idea of building software in the first place for many people. Proprietary licensing schemes, however, are not always beneficial as mentioned above; some of them remain controversial and interfere too much with a user?s rights, especially nowadays with restrictions such as always-on DRM. Open source licensing schemes entail a much less restrictive air to them, and most users prefer them to proprietary licenses; what they lack, however, is any sort of warranty or guarantee that someone will fix your problem if you decide to use that piece of software. Both have their pros and cons – I think DRM gets a pretty bad wrap these days (and deservedly so in a lot of situations), but it makes a lot of sense for developers who want to make money off of their products. But if you’re building something that other people or developers can use and is for the general betterment of society, why not give it a free software license like the GPL?

The Building of Go Wiki – Part 1

I recently completed my first true project in Go: a fully RESTful wiki that is persistent through a MongoDB database. Since Go is such an upcoming language that many of us haven’t been exposed to yet, I wanted to write about how I built it and go through some of the architecture involved with the wiki in case anyone is interested in how Go works. If you have any feedback for me, let me know!

Check out the live site and the GitHub repo.

The Main File

Let’s jump right into the main file that starts off this wiki:

Just like C, C++, and Java, Go looks for a main method to start everything off. We’ll get more into the guts down below, but starting off in the first few lines we’re importing some necessary Go packages. After that, we’re reading a config file in order to set some global configuration, and then we’re establishing connections with the MongoDB collection. The rest of the main method is dedicated to starting a simple HTTP server on port 8080, and routing different urls to certain handlers.

You may notice the use of the keyword go here; no that’s not just a fancy way to say I’m using Go – it forces the function passed to it to run as a goroutine. Go is built around the concept of concurrency, and therefore it’s very easy to run commands in their own ‘goroutine,’ or thread. Additionally, Go also makes it very easy to talk between those threads using ‘channels,’ which are very useful, but not discussed in this post because I don’t need to communicate between goroutines. In fact, I am running each handler in its own goroutine because each handler is very modular in nature, and doesn’t depend on any other handler.

Reading Configuration

Reading configuration in Go isn’t a default feature, but we can do it with the help of a package called gcfg, which allows you to create config files similar to an INI file. Here is an example config file structured properly for Go Wiki:

Then in our code, gcfg allows us to create a Go struct (similar to a struct in C, and a class in an OOP language) out of this config file like so:

Because the Cfg variable and ReadConfig() method start with capital letters, they have public scope and can be accessed outside of their main package after being imported; otherwise, they would be private variables and functions. If the config can’t be read properly, the program exits with an error.

Establishing DB Connections

Go Wiki uses MongoDB, and there’s a very well-built ORM for Go that I chose to use called mgo. I’m very impressed with how all-encapsulating mgo is considering how new Go is, and it handles all interactions with the mongo API beautifully. Let’s take a look at how we use mgo:

This establishes a connection based off our previously established config, and sets the desired collection to our global Collection variable, which is the only collection we deal with in this wiki.

The Page Struct

The core of this wiki revolves around a struct called Page. This is the struct that we use to encapsulate our attributes for each wiki entry, and also has methods associated with it such as loading, deleting, and saving an entry to the database. Here is our main page.go file which houses all page-related code:

There’s a lot going on here, but in nutshell, we create a Page struct that holds title and body attributes, and then we give it methods for saving, deleting, and loading an entry from the database.

Here’s an awesome bit about Go – you may have noticed that the Delete and Save methods are preceded with a set of parameters. In Go, this is what is called the receiver, and it declares the variable that has parent scope over that function; in layman’s terms, it becomes the ‘this’ of the function, but assigned to whatever variable you want. If you’re familiar with javascript, it is similar to running .bind(this) after a function call, which redefines the ‘this’ value to the scope outside that function.

For the Save and Delete functions, we set the receiver as a Page struct so that we can directly use the calling Page instance with all of its attributes in the function (remember that Go is not an OOP language, so the ideas of OOP encapsulation don’t exist here). We’ll see how to use these methods in our route handlers.

How About the Route Handlers?

Now that we’ve established our foundation for the Go Wiki, we need to handle the logic that happens when we navigate to the wiki itself and interact with it. But I think we’ve covered enough here for one day; we’ve established a firm foundation where we have our ORM set up based up on configurable options, and we’ve set our architecture up to be able to handle creating and modifying wiki entries. Next time we’ll cover in-depth using Go’s net/http package to validate and extract parameters from our URL, handle actual logic such as interacting with the DB, and use the net/http package’s templating language to access our Go variables in our actual HTML templates (similar to how ERB, Twig, Handlebars, etc. work).

Stay tuned!