mchls.works

Going remote: One year with DNSimple

Wed, 27 Dec 2017 00:00:00 +0000

Going remote

As mentioned in my previous post, I am working remotely for about a year now. I wanted to work remotely for quite some time before that. Getting a remote job is quite hard, as most companies want you to have existing remote work experience already. So getting into it is tricky. I managed to join DNSimple after a period of a short-term contract.

When I announced that I’m joining DNSimple my friend Daan challenge me to blog about my experience.

I would be very interested in knowing how you first day/week/month/year will be. Care to blog about that?
— Daan van Berkel (@daan_van_berkel) January 4, 2017

So here am I summarizing my first year of working with DNSimple. Whenever I mention that I am working remotely, I usually face the same questions. Here are the Top 3 and their respective answers.

FAQ

Where is your company based?

We have no headquarter, the company DNSimple is a US company. But the team is globally distributed across six different countries.

So you are working from home?

TL;DR: Sometimes.

It depends some month I prefer staying at home, but I quickly realize I’m not that productive and staying at home the entire day drains my mood. I also work from various co-working spaces, some month I spend a more or less regular working day there. Others I’m only there to attend a conference call.

But my most favorite places are coffee shops, I wrote an article about the dos and don’ts of working from coffee shops. Coffeeshops are great because you have people around you it’s a busy environment but allows focus (for me).

Are you lonely?

No! I’m part of a team, we work together, we are just not in an office. We’ve Slack that’s our company water cooler, where you meet your coworkers, joke around and chit-chat. Say hello when you arrive and let others know when it’s time to pick up the little one from the Kindergarten.

We also see each other at least three times a year at a tremendous sunny place somewhere on earth when we have our team meetups. This year, we’ve been to the south of France, Rome and the USA.

If I feel to urge to have actual human conversations, it’s OK to take the time to just meet a friend for an extended Lunch. That’s part of working remotely too.

Frustrations

When I started I remember one of the biggest frustrations was to keep up with everything that was happening. Slack is a firehose. Every commit, every PR, every signup and every human is posting to the chat. A LOT. I wanted to read and understand everything. There is so much going on, and I had questions about every single bit.

In hindsight, this is great. It creates the feeling that you are not working alone, and even if no one is actively chatting, you see that others are around because they trigger the web hooks that fire into chat. Now, this firehose creates a warm and fuzzy feeling for me.

Celebrations

There is so much to celebrate it’s hard to pick the most and single best thing. For me, it is the fact to work with brilliant humans, that are eager to teach. I can learn so many great new things in a field I am very interested in. Still, there are many things to learn and areas to improve technically and especially personally.

I am thankful for being presented with the opportunity and working with so many great and wonderful humans. Thank you wonderful humans of DNSimple onwards to the next years!

#jimdoquit one year later

Thu, 26 Oct 2017 00:00:00 +0000

This day exactly one year ago I was fired.

Actually, I was one of about 70 people, around 25% of the company, which were fired as part of a mass layoff. Here is what happened that day.

Getting fired

The whole company was gathered in the huge kitchen area to listen to a short announcement of one of the founders that they missed to place effective structures and that they will have to fire 25% of the company to accelerate again.

The whole time the atmosphere was super strange! I knew right from the beginning that I would be part of the 25%. I told my boss the day before that I’m about to quit. Turns out most of the people in our group were about to leave, like me.

Obviously this was not true for everyone, some people were shocked because they have not seen any of this coming. They felt as integral part of the company.

#jimdoquit

I went back to my desk to pack my stuff and tweeted this:

To you my lovely fellas 💖 #jimdosplit #jimdoquit pic.twitter.com/Qs4nnwZxpg
— Ole Michaelis (@OleMchls) October 26, 2016

– #jimdoquit was born.

One thing that stuck with me: They even prepared IKEA bags and placed them in the hallways. I’m still torn if this was either a super nice thing to make this day a little bit better or if this was the absolute sign that we are just human resources that need to leave asap.

This #jimdoquit thing took off like crazy. Almost every company in Hamburg and many many others from Germany posted their job offers with that hashtag. They were after us on Xing, LinkedIn, and basically everywhere.

That’s what happened that day, but for me the more interesting days were just ahead.

Feeling the support

I’ve meet tons of people from around Hamburg in the days after. I think they enjoyed the chance to talk to someone who was affected and I had the chance to grow my network and check-in with possible new employers. In general, and here is a take away for you, everyone wants to hire software people. At no point in this journey I had the fear of not getting food on the table.

Everyone was so supportive; the affected people were organized in facebook groups to catchup and exchange job offers. We took application training at my friends from alphacoders and helped each other by checking our CVs.

I still remember two cases that I appreciate a lot. I was having a (sort of) interview and had to take a very important phone call; instead of getting weird looks I recived all the support with a quiet room and a shifted meeting. The other occasion was a former co-worker who is now running a company as CTO. He said I should really look for what I wanted to do and if this takes more time he’ll hire me to bridge the gap.

Thanks, mates ❤️

One year later

One year has passed since then. The time has helped to let this situation sink in and reflect on what happened. I am thankful for the time and opportunities I had. But still, getting fired is something that stinks.

I have now joined DNSimple working in a globally distributed remote team; working on products for other tech people. How I landed that job is a story on it’s own that I will most likely publish soon.

If you ever find yourself in the same situation, do not let this get you down. Ask your peers for help or get in touch with me; I’m also always happy to help.

Let's Encrypt (beta) on rails

Thu, 22 Oct 2015 00:00:00 +0000

Let’s Encrypt is here to fix the web with free SSL certificates for everyone, and I hope they will gain a lot of tracing with this! slidr.io was choosen as a beta tester. And operates with a Let’s Encrypt certificate I want to share how I got through the challenges with my rails app hosted on Heroku and uploaded the certificate.

Setup

Follow the steps in the installation instructions.

Generating the certificate

./letsencrypt-auto --agree-dev-preview --server \
      https://acme-v01.api.letsencrypt.org/directory auth

The first question is if you’d like the standalone verification or the manual one. I’d go for the manual one as I’ve no access to the “server”.

The client will ask you for the domain(s) you want to have included in the certificate.

Next you will be presented with a challenge which looks basically like this:

Make sure your web server displays the following content at
http://slidr.io/.well-known/acme-challenge/<some hash> before continuing:

{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "..."}}, "payload": "...", "signature": "..."}

Content-Type header MUST be set to application/jose+json.
[...]
Press ENTER to continue

headsup: the url is http, and as of now their client does not follow 30 redirects, also non to https :wink:*

Passing the challenge with rails

To pass this challenge I’ve to get my Rails app to respond, here’s the change set I’ve figured out working nicely for me:

# config/routes.rb
get '/.well-known/acme-challenge/:id' => 'welcome#letsencrypt'

# app/controllers/welcome_controller.rb
def letsencrypt
  response.headers["Content-Type"] = "application/jose+json"
  render body: '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "..."}}, "payload": "...", "signature": "..."}'
end

As I mentioned it will not follow redirects, so make sure you temporarily disable it.

# config/environments/production.rb
config.force_ssl = false

Uploading the certificate to Heroku ssl

After pressing Enter and waiting a few secs, I was presentes with the following message

IMPORTANT NOTES:
 - Congratulations! Your certificate has been saved at
   /etc/letsencrypt/live/slidr.io/cert.pem and will expire on
   2016-01-20. To obtain a new version of the certificate in the
   future, simply run Let's Encrypt again.

Now I had to upload the cert to Heroku:

sudo heroku certs:update /etc/letsencrypt/live/slidr.io/fullchain.pem /etc/letsencrypt/live/slidr.io/privkey.pem

headsup: it is important that you choose the fullchain.pem because otherwise some browsers might mark your site as untrusted.

That’s it already. I hope this little guide helps you too, or gave you some insights how the Let’s Encrypt process looks like.

I also want to say a huge THANK YOU to everyone involved with Let’s Encrypt it’s a great project involving a lots of efforts. You folks rock! <3

DevOps @ Jimdo, conferences and slidr.io on a podcast

Sun, 16 Nov 2014 00:00:00 +0000

I was a guest at DESCRIPTIVE a podcast from my friend Kahlil Lechelt. I talked about various topics, including how we do DevOps at Jimdo, the stoy of so coded and the bliss I found in developing slidr.io.

You can find the shownotes and the podcasts subsribe button here http://descriptive.audio/episodes/6.

Enjoy!

Finding Your Voice

Fri, 15 Aug 2014 00:00:00 +0000

this article was initially published with the March edition of php[architect] magazine. I want to thank them that they allowed me to published the post here on my blog, too!

It’s (mostly) always the same story: I’m trying to convince some of my friends to finally submit a talk to a conference Call for Papers (CfP), and the answer is always: “Yeah, I would love to…but I have no idea what I should talk about.” It’s time to get over your reservations and find your voice.

Step 1: Finding Your Topic

Since I have been hearing this so often, I want to share some of my thoughts on finding a topic and becoming the best speaker to present on it at any conference.

I started speaking at conferences almost two years ago. Since then, I’ve been to a lot of conferences. I was very lucky because my CTO back then was an experienced speaker already. He gave me a bunch of good advice and helped me to find my very first topic. Today, I am going to pass this advice on to you.

I assume you are getting your monthly paycheck for a reason, which means you are actually adding value to your company’s goals. Are you programming new features? Great - go talk about that. How about sharing: ‘How we evaluate which features are worth being implemented’? Are you fixing a lot of bugs? That is also a great topic to talk about. How about: ‘The top five ways to drill down and find EVERY bug’? You may even be doing a bunch of other stuff besides programming - proper project management, prototyping, or technical evaluations - and these are also great things to talk about.

This brings me to my next point.

Very often after giving a talk, what I hear is that I’m so passionate about the things I’m talking about. The reason for this is dead simple. I am enthusiastic about the things I’m talking about. You should be too. Don’t just pick a topic that’s worth sharing. Pick a topic where you really feel like it’s an amazing thing - it’s the one tool, best practice, or workflow that you can’t live without anymore!

That being said, there is one last thing you really should know about finding talk topics:

Even Though You Know It, Not Everyone Else Knows It

That’s really the biggest takeaway of this whole article. To be able to talk about a topic, you should really feel comfortable with it - whatever it might be. We all know that it usually takes at least a couple of months - or even longer, possibly a year - to dig into something well enough to feel comfortable with it. Which brings us to the actual problem: As soon as you know a topic well enough to be able to speak about it, you feel like the topic is so easy that you expect everyone to already know about it.

YOU ARE WRONG! You should feel special for knowing that thing. Ask your peers if they would be curious to see a talk about that topic.

Step 2: The Abstract

Now that you have a rough idea for a topic, it is time to write a nifty abstract for your idea. Let me tell you my little secret about abstracts: Be as specific as you have to, but try to be as least specific as you can. I usually write my abstract without knowing how my story will look in the end. By keeping it a bit vague, you are preserving the chance to change bigger and smaller details while crafting the talk.

If you’d like to get an idea of how other speakers are writing their abstracts, there is a pretty obvious way that most people forget about. When you are reading through a conference program, you are just reading a collection of abstracts (and ones that were successful at that). I only know of a very few number of conferences where they ask speakers to write an extra paragraph, separate from their proposal, for the program, so just read through a bunch of programs from your favorite conferences. This way, you can get an idea of what the best writing style would be.

You are almost there, but there one last thing to do.

Step 3: Name the Talk!

As we all know, there are just a handful of unsolved problems in Computer Science, and besides printing and dual screen solutions, it’s naming things. This, unfortunately, also applies to finding a name for your conference talk. At this step, it’s a lot about your creativity. Try to make the audience curious, but don’t make false promises. Try to tell them what they can expect and what kind of level your talk will be at…and pack all this information into about 40 to 60 characters. Good luck!

You’re Done

I hope this made the process of how to get your paper into a CfP a bit more clear and also encourages you to share what you already know. People speaking at conferences aren’t super heroes or super brains. The only difference is that they have realized that they have something to share, and now, you have too!

Docsplit on heroku

Tue, 04 Feb 2014 00:00:00 +0000

I often search the web for things! But in roughly 20% of the cases even google don’t have the answer to my very specific questions. So to prevent you I just want to blog more often tech stuff again. So lets go!

For my side project slidr.io I choose heroku as a platform, because hardware sucks. But it’s (beside my current work project) my first “real” thing on heroku. So I sometimes stumble upon things I have no clue how to solve it in heroku-candyland. Like recently I wanted to use Docsplit a gem which has dependencies to some system packages.

After searching the web for quite a while I found ‘heroku build packs’ will be the solution for that. But I needed more packages and build packs usually only fulfill one dependency. So we need the multi-buildpack. You can use it for your current app like this:

$ heroku config:add BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git

Now you can go ahead and search the web (or basically github) for all the build packs you need for docsplit to run and put them into your .buildpacks which should be located in your projects root.

λ  slidr.io git:(master) ✗ cat .buildpacks
https://github.com/mcollina/heroku-buildpack-graphicsmagick.git
https://github.com/BauCloud/heroku-buildpack-poppler.git
https://github.com/elbongurk/heroku-buildpack-ghostscript.git
https://github.com/heroku/heroku-buildpack-ruby.git

This is how my .buildpacks looks like and docsplit runs very fine so far.

I hope this might also help you, just drop me a line if so or even if you might encounter any issues.

Programming Motherfucker or how I rediscovered my hacker spirit

Thu, 12 Dec 2013 00:00:00 +0000

When I was 18, still living at my parents house, a good friend of mine and I volunteered for Europe’s biggest internet radio #Musik to rewrite their website. I was still a trainee at my current company and had a normal 8 hour working day. Right after finishing that, I arrived home and started hacking the website. It was a hilarious time, but I learned a lot and we had so much fun! We also made a lot of mistakes, like writing our own framework and implementing every shitty component on our own. And even if PHP 5.3 was there at the time, we didn’t give a fuck about name spacing our code and such.

The site launched right before our final exam. When we were done, we parted ways. I became a Lead Developer at the company we were working at and ended up with much less time to hack on things I enjoy. I had way too many managing tasks back then. I just lived my programmer’s life and had some good and some bad times, including awesome inspiring conferences, some cool projects and a shitload of new things I learned.

In the middle of 2012 I had my very first public speaking gig at the phpunconference here in Hamburg. It was so much fun for me that I decided to do this more often. I submitted my talk here and there, ending up with my first international speaking gig at TakeOff Conference 2013. I went there with 2 friends of mine and we had an awesome time in north France. The Take Off Conf organizes were running that conference for the very first time, and they did an awesome job, but there were still a few little things which annoyed us. It made us think:

If we were running a conference we would do it different

This is what happened eight months later. We spun up our very first conference and So Coded 2013 was a thing! Organizing this was a rollercoaster ride, and right in the end sprint of organizing the event, my two friends became unemployed for (conference) unrelated reasons. So our default chit-chat topic was about what kind of business we could create. What could we do for a living? What would be fun?

In the middle of the discussion I thought of a thing which has bothered me for quite a long time. Over the previous year I started speaking at conferences because I enjoy teaching and spreading the things I have learned. And for every conference I spoke at, I always wanted to upload my slides and give that link to the audience so they can check out all the stuff I mentioned later on. But for me as a speaker uploading slides on a shitty conference wifi was always a hassle. The platforms around really bugged me. Some were not free and didn’t followed the FLOSS principles. Others had bad UX and viewing the slides on your tablet or mobile device wasn’t possible at all (from a point of UX and because of iframes and stuff). Think about how often you are checking stuff on your phone or table on a conference. So I came up with the idea to create a slide hosting platform that does not suck. This was the moment that the idea for slidr.io was born. I just wanted to get rid of that pain I experienced so often.

While still in that same Cafe, I immediately registered the domain (on my phone thanks to DNSimple). And due to that fact that 2013 was the year I finally wanted to dig deeper into ruby, I decided to use Rails as a framework. I had the complete software stack in mind. It didn’t cost me any effort to think what I would need, I just knew what I wanted to build. So as soon as I got home I started hacking away. I hacked the whole night till the early morning hours, no matter that I had to go to work the next morning again. I read a lot of documentation, played around with Rails, searched for a plugin for handling auth, and figured out how to run a rails app on Heroku. I had a very very basic setup running by the end of that first night. That was now about 50 days and 80 commits ago. And since that day I have rediscovered my hacking spirit. I just want to get things done, I want to see progress on the tool I want to build, the tool with which I want to change the industry.

As I mentioned before, I’ve attended so many conferences and I always saw so many fellow nerds hacking (not surfing Facebook) with every free minute they had. I was kind of jealous, because I knew that feeling but it had been for a very long time. But now I’m also one of these people. I grab my laptop with every free minute to improve what I’ve built so far. I hack when I wait at the airport for my next flight. I hack at night and when meeting friends in a cafe with the sole purpose of hacking together.

I asked a bad ass UX expert and friend of mine (Fabian) for help, and lucky me, he also really liked that idea and the challenge of creating something new on a green field. So as of now we are a team of two passionate developers / designers getting our own playground for new technologies we always wanted to play around with. And we aren’t just making a demo for the purpose of testing things, we are building a real app.

In the past few days, I’ve been thinking about what happened over the last few months, and I realized that whenever I share this story I inspire people. That’s also why I am sharing the story here. Sometimes I’m afraid that I’ll lose this feeling again, and I don’t want it to take me another 3 years to rediscover it.

I cobbled together this logo so that I don’t forget that,

I decided to use the term made popular by Zed A. Shaw: “Programming Motherfucker”. It has a different meaning for me than being against all the Agile stuff which is happening in our community.

It’s more about doing what you love, focusing on why you started doing this kind of job, remembering the reason why I work in this industry. It’s about programming, having fun making things, and creating software and maybe changing the world!

I want to make stickers out of it, use it as wallpaper and place it everywhere in my life. Anything to keep myself from forgetting what I am really passionate about.

Programming Motherfucker!

Note: please feel free to use this ‘logo’ and to place it in your office, bump it to your co-workers screen or paint your wall with it!

Bring the valley!

Fri, 18 Oct 2013 00:00:00 +0000

I will make the valley know, that Hamburg is way more awesome then Berlin!

This is a quote from the So Coded Conference after party. And this, for me as one of the organizers, is one of the biggest compliments we could get. Many people asked me: “Why do you do this?” Well, that’s an obvious question, right? And with this blog post I will try to explain why, especially in relation to the quote above.

I love the Valley, or more specifically, I love the hacker spirit around there. So many cool tech companies want to change the world we all live in. In every café you enter, you will find nerds sitting in front of their MacBooks, hacking on new things. So what’s cool about this? These people don’t do it for the money or the fame they might get. They do it because they believe! They believe in the things they build – they believe they can change something. It’s the hacker spirit I love and it is tech people like us that are creating this.

So when I came back to Hamburg again and took a closer look at the few startups around, I quickly realized that these startups are different, different in a bad way. Almost all of them are founded by business people just trying to create the next Facebook and earn a shitload of money. Some just want to create a cheap, shitty copy of Y and get some money. This fact really bugs me. So what to do?

One possible option is to just move to the Valley. I guess almost everyone of us had, at some point, thought about this. And never say never, but for the moment Hamburg also has some upsides for me. My wonderful girlfriend, my family, and the wonderful city itself. So there must be another option.

If I can’t go to the valley. The valley has to come to me!

Pushing the tech community in my hometown was one of my personal goals that I wanted to achieve with the So Coded Conference. Running a conference is obviously only one aspect of it. It’s more about enabling people. Giving them permissions, the permission to build awesome things, the permission to change the world, and the permission to just be awesome, as Adam Brault stated on the JSConf.eu closing keynote this year. Thanks buddy, this keynote was very inspiring to me

What’s the point then? Well I need your help! This isn’t my mission, it’s ours! Running events like user groups, giving them a place to happen if your office allows it, or organizing free programming lessons for interested people. So many great examples are around already, and there are so many organizations that exist to support you if you want to pitch in! So many companies are willing to help! And at this point, I just want to say thank you to all the people and companies making this happen. And of course this does not exclusively apply to Hamburg, if you feel your city’s tech community should improve, change it!

Coming back to the initial quote, X is way more awesome then Y? That’s not the point I wanted to make. It’s just that I was overwhelmed by the feedback we got in general. This really empowered my desire to continue my mission.

In closing, I just want to say thank you to all the people inspiring me to do so!

Could I become an Ops please

Wed, 08 May 2013 00:00:00 +0000

I started at Jimdo in December 2012, ready to change everything and bring in all my gained knowledge in Software Design and Service Oriented Architecture (SOA). I already knew that the Jimdo system was approximately eight years old, so what we all call a “grown system”. In fact this means that there are a few thing I would do “better”, like we have code tightly coupled to the hardware structure and also into itself. No SOA at all, but I want to change that, as I was hired for the Feature team, I quickly realized that I obviously couldn’t do it alone. I teamed up with Sönke and joined the Infrastructure team. He has been at Jimdo since 6 years, so he does not only know a lot about the system, but also is a great software architect.

Why I joined the Infrastructure team?

Well, I realized that before we can refactor the software we have to do some operations work. The Infrastructure team at Jimdo is responsible for two different tasks:

Keep the system running, we have a bunch of hardware servers, so we have to deal with many disk failures and network issues.
Improve the system, we are all very annoyed by the things mentioned above. So we can’t to get rid of “möhrchenkonzept” (that’s how we call it internally), which means putting old parts of the system out and putting new stuff in.

Hired as an Open Source Rockstar (or technically speaking “Software Engineer”) - I ended up as an Ops guy just a month after I started. This was and still is a great opportunity to learn, not only for me, and I’d like to say that every developer should do this.

Things I learned so far:

Beeing on-call, this actually is one of the hardest things I had to learn. As an Ops guy you are FUCKING RESPONSIBLE for the system, not only when you’re in the office or in front of your notebook. You should respond to an alarm within a given time, so no partying, no real chance for any activity where you cannot react within a reasonable time frame. Of course you also have to get up in the middle of the night. Think about the things you’re doing over the week, and if you can also do them when you are on-call.
Deploying to production can cause a collage to spend the night infront of your notebook. You should develop, as if you have to get up when your deploy cause errors.
There’s no magic involved, your code is always running on systems which have, somehow, to be maintained. Of course you can reduce the amour of work that has to be done with cloud solutions. But these could solutions can only reduce the work which results from hardware stuff. But when you are coding crap even Amazon can’t help you. So sorry friends, I know, the truth can hurt. But there’s no shiny candy land out there which can execute code.

This can be a little bit catchy For me people who have never used linux as an operation system are no real developers. It’s more than mandatory to know the platform your code is running on, as I mentioned above. And most of our apps are hosted on an some kind of linux distribution. I’m also a Mac user, but before I switched to Apple I used Ubuntu for quite a long time. And this now helps me a lot, so that I know at least the basics in operations business. Maybe I should rephrase this: Every software developer should have at least some shell and unix knowledge.

So grab your ops colleagues and maybe offer them a little position exchange (everything included, also being on-call) for about a week or so. You will see this will change your mind and you will gather some more insights and gain a better understanding of the so called “system administrators” in your company. Oh and I finally learned some puppet, too.

Sidenote: If you like this topic and want to hear more of this, I will give a Talk on this topic at ThatConference in Wisconsin this August. If you’re also curious about this topic please step by and let’s have a talk.

Jimdo also has a Developers Blog you definitely should follow. We try to blog about more specific things we archived so far.

Hubot on nodejitsu

Sun, 10 Mar 2013 00:00:00 +0000

A few weeks ago I finally managed to deploy Hubot on nodejitsu, as I’ve read a few times people want to know how this works, heres my tutorial.

###Prerequisites First of all you need a deployable version of Hubot

git clone git://github.com/github/hubot.git
cd hubot && npm install
bin/hubot -c ../deployable_bot
cd ../deployable_bot && npm install

Now you have a deployable version of Hubot in the deployable_bot folder. Next step would be to configure your adapter. When your done with this, you have a runnable version of Hubot. Now let’s move on with the nodejitsu part. I assume you have your account and the cli-tools properly set up.

###nodejitsu and cli flags As you might have noticed nodejitsu isn’t able to take cli flags. But we need them to make Hubot run properly. Luckily we can configure Hubot also via environment variables. So let’s move all the needed parameters into the package.json, every cli flag is also available as environment parameter with the HUBOT_ prefix

{
  "name": "demo-hubot",
  "scripts": {
    "start": "node_modules/.bin/hubot"
  },
  "env": {
    "HUBOT_ADAPTER": "xmpp",
    "HUBOT_NAME": "demobot"
  }
}

note: with nodejitsu you can also store your environment variables in the WebOps interface. Because you’ll have a lots of passwords in your environment variables, and I really suggest not storing passwords in any repository.

###deploy on nodejitsu

This is properly the easiest part

jitsu deploy

Your application will be created if it’s not there yet. Your robot should now join your configured chat.

###why nodejitsu? when there is already heroku support

Here are a couple of reasons:

I like new stuff
nodejitsu is for node
there are no dynos (so no idle timeout stuff)
Zero Downtime Deploys

###is there more?

Oh yes! You can have auto-deploy or check out Hubot docs or nodejitsu docs. Hope you this works for you as good as it does for me. If not, just drop me a tweet :)