Employee Scheduling Software

I’ve been working on this for a while and finally think it’s good enough to release to the world. You can now sign up for my employee scheduling software. Scheduling is employee scheduling software that lets you manage your work schedules quickly and easily. It’s best suited for businesses that have employees that work something other than the typical 9-5 shifts such as restaurants, offices, etc.

Employee Scheduling

If you make schedules, Scheduling allows you to easily make a schedule, remember requests for time off, post the schedule for employees, and more.

If you’re an employee, Scheduling allows you to easily request time off, communicate with the rest of your office via the wall, and quickly and easily see when you work.

Tech wise, it’s written using Rails 3, resque, Apache, and passenger. There are a lot of places I’d like to take this software and look forward to maintaining the app and adding more features. I’ll also do some technical posts later about getting everything working.

So check out the app, tell your friends, and let me know what you think!

Rails Envy

Many have asked what happened to Rails Envy so I thought it was time to tell the story. Fair warning: this gets a bit personal at times.

A Brief Bit About Me

I went to school for Psychology where I got a Bachelor of Science at the University of Central Florida. I took some programming classes but was always a "closet geek." I’ve been programming since I was 6 years old and Ruby and Rails just felt right when I found it. Even more so after coming from PHP, Perl, C, and (shudder) some MS Access coding. Right around when I was finishing college I started attending ORUG meetings and some hackfests. This is where I met Gregg Pollack. We got along great, especially with coding.

Where Rails Envy Came From

I think I attended all but the first Orlando Ruby Users Group and occasionally gave presentations. On the Tuesday, November 14th meeting I gave a presentation on using RJS in Rails. I actually thought it was a good idea to use the term "AJAXified" in a presentation description, but I digress. That night I was joking around with someone and we decided a local [insert other language here] developer had "Rails Envy." At the time, I thought it would make a pretty funny Rails focused blog name so I registered the domain. Then I sat on it for a while.

At some point in all this, Gregg, who has his Patched Software consultancy at the time, asked me to come work for him on a contract basis because he needed help on a project. This actually terrified me at the time. What would I do when the contract ran out? How would I find other work? I was pretty fresh out of college and hadn’t considered going contract. After talking it over with a lot of people, I quit my job.

Full Time to Contract

Me and Gregg
This picture has nothing to do with the paragraph, but it’s from that time period.

Coming from the full time employment world, working on a contract basis was a wonderful experience. I was working while wearing a t-shirt and shorts! Plus, the work was fascinating to me. I remember working with Gregg to solve some very interesting Ruby and Rails problems of the time. There were always people blogging but not as many as today and a lot of the time you had to dive deep in to Rails rather than googling solutions. It’s inspiring to see how far Rails has come.

After I working with Gregg for a little while I convinced him that we needed a blog. Gregg wasn’t convinced we were qualified enough to write a blog. I remember saying that we didn’t have to be because we had something to offer people based on our experience developing Rails full time. This was a different time — not many people were doing full time Rails work. We used, set up Mephisto, and we were rolling.

We weren’t expecting the amount of feedback we got. It was great.

We Make Some Videos

I remember leaving ORUG one night and saying to Gregg "Wouldn’t it be funny if we parodied the Mac vs PC ads only using Ruby on Rails and other web development frameworks?" I was just joking but Gregg convinced me it would be a good idea to actually shoot these. I remember writing some script on a notepad during ORUG about a guy running in a track suit. I’m really glad that one didn’t make it in. Anyway, Gregg set up a writeboard (password: railsenvy), we bounced some ideas back and forth, got in touch with a friend of mine who did video work, and actually shot the videos.

Shooting the videos turned out to take a lot longer than I expected. It also was much more fun than I expected. I think the original set of four took nearly two full days including rehearsals. I still love the bear in a jar for hibernate. The videos went viral and that was awesome. I think I have a screenshot somewhere of 3 of the videos being in various spots on the front page of digg at the same time.

Gregg managed to get in contact with Chad Fowler and have the videos played at the first Railsconf. That was a truly exciting experience. I wasn’t expecting it at all and was flattered that they even considered playing them. After Railsconf we made some more. To this day I’m still embarrassed by the myspace one.

Hey, Let’s Start a Podcast!

Rails Envy

I wasn’t much of a podcast listener. Gregg turned me on to the amazing Radio Lab and This American Life podcasts. I had noticed at the time that there weren’t any Ruby or Rails news podcasts. I remember it took some convincing of Gregg to get one started. My original pitch was something like "Just a five minute thing where we read what’s new. We’re reading all of the RSS feeds anyway" "Why would people listen to us when they could just read RSS feeds?" "Some people like listening to podcasts. And we’re funny." After doing some research on how to set up a successful podcast (Thanks Miles and Ryan!) we were up and running.

I learned a ton about editing podcasts. Dan taught me why I should use compression rather than normalization under certain circumstances. For the longest time, I used Soundtrack Pro to edit the podcasts. I think I did the first 40 episodes in Soundtrack before learning Pro Tools. Gregg and I would record each story separately and assemble them later. It usually took three takes if we messed up. Which was often. Looking back, I can’t believe I edited over 90 of them. Every week. It was a lot of work but I loved doing it.

Rails Can’t Scale

Can Rails Scale?

I think a lot of people were wondering why a Rails developer would be saying that Rails can’t scale, very often at least once a week. When I started this meme there were a lot of blog posts and questions about the time about Rails and scalability. People were citing Twitter as an example of Rails not being able to scale during their fail whale days. Java people were saying Ruby is slow. TechCrunch was all over it.

My idea was to make the expression "Rails can’t scale" so tired out that people would get sick of hearing it. When people commented asking me to stop, I knew I was doing a good job. Sorry everyone. But it was for a good cause. There’s a lot less sentiment these days about Rails not being able to scale. I’d like to think I played a small part in that.

Working for The Man!

Halogen Guides

Gregg and I were approached by Dan Benjamin about working for a startup called Helium Report (now Halogen Guides). We accepted. I got the opportunity to work with a kick ass team. I have nothing but praise and respect for everyone I worked with. We had our challenges but I think we handled them well. I wrote some pretty good code, if I do say so myself. However, for reasons I’m about to outline, I wasn’t able to keep the job.

Tragedy Strikes

This part is difficult for me to write. Gregg mentioned in his post that I moved to Ft. Lauderdale for a year but didn’t say why. On May 1st, 2008, my mother woke up to find my father missing from the house. She was very worried and under a lot of stress at the time. My sister and I eventually found my dad, though my mother suffered her second heart attack while we were looking for him. She passed away a few days later.

Words can’t convey how deeply I miss her. I think about her every day. She was an amazing human being and I’m proud to be her son. I owe her a lot and I’m largely the person I am today because of her.

I’m not sure people ever really "get over" these kinds of things; rather, you find a new normal. I got a lot of supportive emails when Gregg announced this at the end of the podcast. I’m sorry if you emailed and I never got back to you.

I wasn’t able to keep a job while all of this was going on. However, everyone at Halogen Guides was ridiculously, above and beyond, supportive. For that I’m extremely grateful. I wish everyone nothing but the best.

Some Good Comes out of it

My girlfriend Candace and I moved to South Florida to help take care of my father. She selflessly changed jobs and moved in with my father and I. This sealed the deal in my mind and I proposed. She said yes. She’s a wonderful person and we’re getting married September 25th, this year. I couldn’t be happier, even though I’m a bit difficult at times. I probably wouldn’t have been able to get through everything without her support and the support from some very good friends. You know who you are. I thank you all deeply.

Wrapping Up

With me living in South Florida and Gregg in Orlando, each working on different projects, it started to become more difficult to do the podcast which was still going strong. We did our best but it started making more sense to split off in to our own companies. I started Twistedmind Inc. where, among other things, I offer consulting services scaling Rails. Dan Benjamin took over the reigns as co-host of the podcast, which we eventually moved over to 5by5. We also started The Dev Show to do a big longer discussion on general programming topics.

Moving On

Though we have mutually decided to take the Rails Envy web site down, I feel that Rails Envy, and what Gregg and I accomplished together, should be celebrated. I’m proud of the work we did and what we accomplished as a team. I’m proud of the videos, podcasts, talks, and client work we did. I’m grateful for the opportunities to have met and worked with so many people. It was a great experience. I hope to continue to set the bar high doing client work through my new company, Twistedmind (Hire me!), being a part of podcasts like The Ruby Show and The Dev Show, and launching projects like Genius Pool and Employee Scheduling software. I wish everyone the best. See you soon.

Developer Job Board

Genius PoolI’m pleased to announce the Genius Pool job board. This is a new job board for connecting companies to job seekers. With the connection to the 5by5 podcast network, making sure your job opportunity is in the ears of qualified applicants has never been easier. Why’s that? If you’re looking for a Ruby or Rails developer, what better spot is there than The Ruby Show? The same applies to The Dev Show. You can also be assured that whomever is applying has an impeccable sense of humor and taste.

So check it out if you get a moment or follow Genius Pool on Twitter for new job postings as they get posted. I’ll be doing some blog posts in the coming weeks about the process of launching your own project as well.

Live blogging BizConf Day 2

Obie Fernandez and Roy Singham

Day 1 of BizConf was phenomenal and I’m going to try and keep up the live blogging for day 2. I missed the lightning talks last night but heard great things from everyone who went. I’ve got my camera charged up today so I’ll try and get some pictures of the presenters as well. Fair warning: I’m really not that great of a photographer.

Roy Singham


Roy Singham

Roy talks quick! I had some trouble keeping up with the wealth of information coming from this talk.

Randomness is a much greater predictor of success than skill. Decoy pricing is probably used a lot by consulting firms. It’s easy to compare a distorted version of something to the non-distorted version than to something else.

Think about your leadership. Write down your top 10 mistakes. Put them in to categories. People mistakes and investing in the wrong person. How you handle yourself in a crisis. When confronted with a huge number of decisions, how do you handle it? Are you confident?

A mistake is something you made in hindsight, not in foresight. The sign of really great leaders is to protect people who have different skills. You have to have people who offset your own weaknesses. Not trusting his gut about a certain person in his organization cost the company a lot of money. Even though he had a gut feeling about this person he forged ahead. Always trust your gut.

There’s no bonuses at Thoughtworks but leaders still focus on money. Even though we would like to believe that sales are driven by supply and demand, we’re closer to ducks. Take the iPhone as an example, and Starbucks coffee. Starbucks is not worth $5/coffee but we’ve been convinced it is. That’s how a lot of consulting companies charge exorbitant amounts.

  • Are they good at their job?
  • Does their boss recognize it?
  • Do they have friends at work?

The average 23 year old expects to have 12 jobs by the time they are 30. That’s almost a job a year.

Roy’s ideas for surviving a recession:

  • No matter how smart you think you are, you will still make mistakes.
  • Massively increase sales force.
  • Double intimacy with customers. Get closer to them. Understand your customer’s customer. If you can understand that, you will create more value for customers.

Take the biggest risk you can possibly think of to create new business strategies. Learn quickly, make it something you can live with. Thoughtworks is engaging five simultaneous new offerings.

A huge limitation of why we fail at software consulting is that people in the software industry aren’t generally aware of how their clients are feeling emotionally.

Think about what you want to be known for when you get older. Make a difference you will be proud of. Success should not be about how big your company is. It should be about how you change peoples lives.

Why Agile Will Probably Fail You

Corey Haines of

Corey Haines

If you’re not familiar with Corey Haines, he’s a "software journeyman." He travels around and pair programs with people all over the country. I’ve had the opportunity to pair with him for a day and it was quite an experience.

Life rule #1: Any time you get to go to the scientist only section, you say yes.

Why do we write bad code?
This is not the question. No one likes to write bad code. The question becomes the following:

When do we write bad code?
When we’re under pressure and have to get it done. The deadline is coming and you’re only 80% done. There’s only so much time left so we start hacking away. "Get it done"e; vs "Do It Right". There’s a perception that when you have to get it done the only way to do it is to hack away.

Constant Pressure
Here’s an idea: if we have developers feel like they’re under pressure at the end of the project, let’s change the deadlines to every month. It would be great if we could let everyone figure out their own process. When people think of agile this is what they think of. Yet the issue of "Get It Done"e; vs "Do It Right&quot is still an issue. Most young people, in terms of a development perspective, only think about today. Scrum assumes that developers self oganize and are responsible.

Corey Haines laptop

Features and Quality
Let’s talk about features. Add a feature to your app. Change a feature in your app. Then time passes. As you work with crap code it takes more time to add features. This brings us to a definition of software quality: having a nominal cost of adding new features. It doesn’t mean there will be no bugs.

Software can be similar to gardening. Gardening isn’t about growing plants. It’s about changing the environment to let it flourish. Add a feature then clean it up. Change a feature then clean it up. Make sure your code base stays clean and boring to add new features.

"If I’m adding a new feature I don’t want excitement"

Why doesn’t everyone do the XP techniques?
We don’t know how. They’re hard to learn. While learning to do TDD a friend of Corey’s took a 70% hit in productivity. So how do you learn to do XP? Most small businesses can’t take that hit in productivity. Work is not practice.

Corey Haines laptop

Becoming a better software developer is about practice. How good would a band be if they only practiced while they were on stage? What kind of quality would a play have if the actors were only given the script an hour before the show? Enter the software craftsmanship manifesto.

Practice Techniques

  • Code Kata
  • Coding Dojo
  • Code Retreat
  • Acceptance Test-based

In the end I think it boils down to this: developing quality software is about taking pride in your work. The software craftsmanship manifesto gives you guidelines. The practices outlined above get you better at it. Take pride in your work and write quality code.

During this talk Jerry got in to a bit of a debate with Corey on practices. While the debate was lively and interesting, this probably could have waited until his talk was over rather than taking time away from Corey’s talk. There was about 25 minutes worth of content Corey didn’t get to. I’m going to be forced to find out about the rest of the content of this talk over scotch later. The horror. I’ll update this post later.

Successfully Managing Local and Remote Web 2.0 Teams

Bruno Miranda of Hoodiny Entertainment

Bruno Miranda

Cyloop is a music site. The first version of the site was in Java. It couldn’t scale. The CEO of the company decided to switch to Rails and hired Hashrocket. They did the 3-2-1 launch. Hashrocket taught the developers, who were all Java, .Net, and PHP developers, about TDD and Rails. Hashrocket’s time lasted about a month. The app was re-launched in about 3 months total.

Having a local team is important. You have a lot of bandwidth to talk and communicate. It can also be distracting. The team uses headphones a lot to reduce distractions. It’s good to have the stakeholders in the same spot as developers. There’s five people in the Miami office, one in Orlando, and remote developers in Brazil. The team tends to type rather than talk, even in person. Typing tends to keep conversations more succinct.

Why go distributed? Bruno wrote a post on his blog about limiting yourself. The Ruby community is small and there’s not a ton Ruby talent in Miami. They would rather not limit themselves to just local talent, they want the best developers. Do video chats to hire people over-seas. Use other resources to find about people. Look at their GitHub accounts. It’s all about finding the right people and staying transparent.

Working with local and remote teams is about transparency. If you don’t know what someone is doing then how do you know they’re doing anything at all? If you don’t have a lot of throughput to talk to people face to face you wind up getting a lot of phone calls and meeting requests. Skype and AIM are “silo” based and talking one on one is probably going to be beneficial so move it to Campfire. Mac folks, check out Propane so you can get your name growled.

In another company, Bruno tried daily standups via phone and Skype but you always waste time getting the mic set up. Daily standups are done in camp fire. Standups are a one paragraph conversation with the rest of the screen. There’s a script that calls for the daily stand-up every day in the Campfire room. Don’t let your standup become a book. NewRelic notifications and incidents get automatically posted in to the campfire team room as well. There’s mainly one product with this company and you may want to move individual projects in to their own room.

They don’t pair all the time. They pair over iChat and Skype. Skype has better sound so disable the mic in iChat.

Projects are managed in Pivotal Tracker and meetings are done with the person who makes the decision. The whole local and remote teams are not included because there’s too many people. There’s a lot of streamlining of the communication process in this company. Your company has to be able to accept change to pull this sort of strategy off.

There’s a strong misconception that you can’t manage a local and remote team. It can be done and it can be done successfully, your organization just has to be willing to accept change. It makes business and financial sense and as long as you get the right people you get quality code. Bruno did a great job with this presentation and made some great points.

Agile, Rails, and the Cloud

Ian McFarland of Pivotal Labs

BizConf 2009

As developers, we build software because it’s cool, fun, exciting, and we love the challenge. Also it beats a lot of other jobs. Companies build software for different reasons. They do it to save money, manage risk, and satisfy business and government requirements. We’re in the middle of a revolution. This revolution in software is about one thing: building better value for businesses for lest money.

Software is expensive. The following are the most expensive with developing software: developers, defects, deployment, maintenance, and change. In the current economy budgets are smaller, the stakes are higher, departments have to do more with less, and failure is more catastrophic.

Agile is business driven: requirements come from business stakeholders.
The customer:

  • The customer is empowered to make decisions and priorities are set by that customer.
  • The customer can change priorities on anything unstarted.
  • The customer accepts the work in fine-grained increments.
  • The customer is intimately aware of progress and projected feedback dates.
  • Closing the feedback loop is critical.

TDD and BDD factors in to this. Good tests tell us when we’ve met the customer’s needs, what’s broken, and lets us refactor. TDD helps keeps you focused: you’re not building features if you don’t need them.

A big part of agile is iterative development. These days, iterations are getting shorter. Because the customer is seeing the work on a daily basis, the feedback cycle is short. This keeps the cost of change low by preventing unnecessary work.

Continuous Integration and Continuous Releasability
There is a bit of a misconception about continuous release. Just because you can release continuously doesn’t mean you have to release continuously.

Pair Programming
You have to pair if you want to be as efficient as you possibly can. As long as there’s more than one developer you’re already pairing. Doing it all the time means you get better at it. Pairing is effective because you stay focused. Developers can get distracted. It’s hard to stay focused all day. At Pivotal developers are exhausted at the end of the day their first week on the job. This is because they’re really not used to coding non stop for 8 hours a day.

BizConf 2009

Pairing helps because you don’t get stuck so you spend more time on the more interesting part of your code. Developers get more well-rounded as they pair. You learn from your pair — design and testing techniques, new development techniques, etc. As a business owner you’re investing a lot in your developers this way. If you’re not pairing you’re throwing that away. New team members can be brought up to speed in an hour when pairing rather than taking a week to figure out their way around. Another benefit to pairing is that you distribute knowledge more. Your bus factor (the number of people who need to get hit by a bus for the project to stop) goes up.

You need to make a productive workspace in a pair environment. Have consistent pairing stations. Pivotal will have breakfast available before the morning stand-up. The reason is that some developers wouldn’t eat breakfast before work and some would. This would result in some developers wanting to stop earlier for lunch than others.

Developer happiness is important to the business. Having a happy developer is important because developer happiness is directly correlated to developer productivity. Productive developers tend to be happier. When you’re doing grunt work as a developer things don’t seem as bad. Happy workers are more focused.

Rails is powerful. Rails goes very well with agile — it’s practically baked in to the culture. Anecodtally, Pivotal has seen a lot of improvements in efficiency with Rails.

The Cloud
You don’t have to worry about buying hardware anymore. You don’t have to be in the infrastructure business. You can scale on demand if you architect for it. You can stay focused on development. This is a big change in the industry.

The enterprise is not quite cloud ready yet. Lots of CIOs really want everything running on ahrdware they already bought. There are sometimes legislative restrictions about having things in the cloud. But it’s getting better. People run HR, CRM, and financials in the cloud now. The cloud is getting closer to being enterprise ready. There are market pressures being addressed every day by cloud offerings. These are all problems we’ve heard before.

In the end, it’s not about the technology. Businesses don’t care about technology. Technology is the means to an end. Think about the technology like a business. Think about getting it done cheaply, quickly, and well. This is why Rails, agile, and the cloud make business sense.


Jose Gonzalez of Hoodiny Entertainment

BizConf 2009

Other than what you’re going to provide, when you’re going to provide it, and how much it’s going to be fore, everything is going to be specific for your business. Don’t accept sloppy code and don’t accept ambiguity in the business. If you and your client don’t understand what it means then a judge won’t understand what it means.

Trade Secrets
Under the law trade secrets are protected as long as they are secret. If you come up with something that is a trade secret the very nature of its protection is associated with its confidentiality. On the other end of this is patents which require you say as much as possible in order to obtain protection. To mark it as a trade secret it must be marked confidential. Do not let anyone see it who doesn’t need to see it. If a client has given you something that is a trade secret it should be market as confidential.

Some companies will put everything as confidential. Some judges will toss that out as a matter of course. As a consultant, everything you learn while in the client’s office should be treated as confidential. That’s just good practice.

If you write the same ten word essay as someone else, both people retain the same copyright. Copyright is the right to stop somebody of copying your work. If you have created something independently from another person then you are not copying.

Trademark isn’t there for you. You need to fight to keep it.

If you’re going to do business, do safe business. Get business insurance.

Merger Clause
It’s a little thing at the bottom of the clause. Anything that anybody said prior to executing this contract in oral communications, written, etc, is gone. If it’s not in the contract it doesn’t exist. Basically, if you want something. Particularly for consultants if there were conversations you had with clients prior to the deal, put them in the contract or they don’t apply.

Understand the Client’s Organization
If someone is the CIO and they hire you, you generally don’t have to worry about hiring issues with them. A CIO would have "apparent authority." You need to make sure that the person who is signing the contract with you is authorized to sign the contract. He jokes that in a bank everybody is the vice president. Don’t negotiate with someone who is seven levels down in a company. You may have already given someone your best deal who has no power to execute on it. Understand the layout of the company before you make a decision otherwise you will be spending a lot of time and energy that might not even apply.

  • If you’re going to make a statement of work they should only have statements specific to the business and scope of the work. There may be times when you come up with a situation where you have an agreement where you have to change something with a specific deliverable.
  • SLAs are nothing more than a way of limiting liability in a specific circumstance. Be careful with them. If the SLA doesn’t meet what you’re looking for it overrides liability. Make sure you understand SLAs.
  • If you need something from the client in order to make something happen put it in the contract. Outline the client’s responsibilities.
  • It all comes down to this: protect yourself. See a lawyer and get a contract made.

Overall this was one of the most useful talks so far of BizConf. Jose thoroughly knows his stuff.