Learn Ruby & Rails in 2.5 hours, for FREE!

I’ve been pretty busy in recent months, but I’ve finally released my Ruby on Rails course. This course is geared at existing .NET developers who want to see what Ruby & Rails is like, but don’t want to invest the time to learn either. In this course, we go through just enough ruby to get you going and build a Rails applications as quickly as possible, with as little effort as we can get away with. You’ll leanr just enough to get yourself into trouble.

The best part is, I’ll let you check it out for free! For those who currently do not have a subscription to Pluralsight, I’ll give you a 1-week subscription so you can check out my Ruby on Rails course. Send me an email with your name, twitter and what you normally develop with and I’ll send back a subscription.

Send email to programmersunlimited@gmail.com

Supplies are limited though!

Tips for working from home

Last week was my first week at my new gig. I work from home full time now. I always hear developers saying they would love to work from home. Granted, it does have its advantages but it isn’t always as great as it seems to be. It isn’t like taking a day off from the office to telecommute (usually I play xbox on these days). Working from home full time requires discipline. Not yet sure if I have it, but it seems to be going ok.

The following are a few tips I found that make things easier for me to work from home and stay disciplined.

Leave for work (Mentally)

When you work from home you have to separate your home life from work life. Even though your office/cubicle is now located in your home, you still have to check out of home mode when you start your shift. Kids, the wife and/or girlfriends should be made aware that even though you are physically accessible  you should be treated as if you’re not actually there. It can be hard, but eventually they will get it.

On the flip side, you must also remember that even though the xbox is only a few feet away in the other room, you’re at work and not at home. The exception to this is the kitchen :D

Leave for work (Physically)

Working from home doesn’t have to mean working from home. I recommend renting a small office space somewhere so that it’s easier to separate home and work life. This is especially beneficial to those with small homes or potentially disruptive households.

I have a pretty big house so space isn’t an issue for me. If you are lucky enough to have a spare bedroom or a den or any room that you can go into and close the door, then move your desk and computer in there and make it your office. Being able to physically isolate yourself will help keep you on track and less distracted.

Additional benefit is if you have kids and you also have to communicate with clients and/or co-workers. You can have a quiet place to conduct business.

Make your space comfortable

Just because you have a space of your own doesn’t mean it’s comfortable. You have to be in that space for 8 hours a day. Personally, I painted my office “Billiard Green” (a nice dark green), setup some soft lighting and rearranged my desk so I could see the entire room (not facing a wall). I moved all of my clutter into the closet and out of the way. I like low light settings so painting the walls a dark color and adding soft light options made a huge difference. It makes the room a place I want to be in.

Get a nice chair, get a nice desk, get some pictures or art or some of those fancy motivational posters and make your work space a place you want to spend all day in.

Stay in one place

This goes along with my previous tip. Make sure your space is comfortable so that you’re not tempted to go and work in your cozy bed or on the big Lazy Boy recliner in the living room. Stay in your space and don’t wander. If you need to “get out of the office” then go down to Starbucks and work there for a bit.

Dress code

WHAT?! Yeah, follow a dress code. Everyone jokes about working from home in their underwear. To help keep you focused and in the work mindset, dress like you would normally going into an office. I don’t allow shoes on the carpet, but I make an exception when I’m “at work”. I wear business casual clothes (or sometimes shorts), and I also wear my shoes. It’s really a mind trick. Make yourself feel comfortable, don’t wear a dress shirt and tie (unless you want to), but also don’t work in your boxers.

Keep a regular schedule

Just because you’re at home doesn’t mean you can’t/shouldn’t take breaks. Be sure to take regular breaks. Maybe two 15 minute breaks and an hour lunch or come up with a schedule that works for you.

When working from home it can be quite easy to fall into the habit of working more than you should. Overtime is fine if you have to get something done, but you should start at a regular time and end at a regular time as if you were in an actual office. No reason to over do it.

Tools & Communication

Be sure you have to proper tools to do your job. If you need to fax then get a fax machine or a digital fax solution. You don’t want to disrupt your day because you have to run down to Staples to send a fax.

Unless you’re stuffing and licking envelopes, you probably will need to communicate via the internet. Make sure that you have quality service. I actually have been fighting with this. I got cable service when we moved in (don’t remember why). Since we only used it for web browsing and Netflix, if it went down it wasn’t a big deal. Well last week I had to work from Starbucks because it went down. It would also go down periodically throughout the day too. It makes for a very annoying work experience, especially since people need to communicate with me and it’s how I do my job. I called and ordered fiber internet and made sure it comes with a 99.99% up time. I also ordered phone service so that I had a land line. Cell service in my area is unreliable. I want to make sure I can do my job and get in touch with people when I need to.

Quality-of-Service

Being in a house with other people who also like to use the internet can cause some problems when they’re eating all of the bandwidth. Most routers support some level of QoS (Quality of Service). QoS basically tells the router that packets going to a certain address are “more important” and they get a higher priority. On my router I give my xbox highest priority (online gaming, Netflix) followed by my workstation. That way my Skype call gets priority over someone else watching YouTube.

Conclusion

These are the tips I have. Basically it boils down to making yourself comfortable but professional, and distraction free. When you go to work, go to work and forget that you’re home.

What tips do you have? What helps you work from home?

Dear employers…

It’s the year twenty thousand and twelve. It’s 62 years since 1950 and 22 years since 1990. Get with the program! Technology has exploded and advanced and so have mindsets. My generation and those who come after me are not ok with working conditions like previous generations were. We are skilled and talented and when you let us be, we’re highly productive too! But as employers, especially those of you who are big corporations that have been around since forever, have yet to realize that you are holding yourselves back by trying to put boundaries around us and treat us like employees of yesteryear.

What the heck am I talking about? Change, man! Technology grows at unprecedented speeds and it isn’t just some fancy word that will be gone tomorrow. It’s here and it’s how you will compete and survive. Learn to use it! Learn to use it properly! Spend the money where it needs to be spent, don’t cheap out! This includes getting (and keeping) good talent. Once you get the skill sets you need, let them do their job! Stay out of the damn way and don’t let the bureaucracy hinder progress and productivity.

Now, you must also understand that once you get your talented people and they are all working happily, that you must try to keep them. It isn’t like it used to be where lower employees kissed up to management to make sure they kept their jobs. We have skills that are sought after and the roles are reversed. We treat employment like the stock market and your company is simply something we hold as long as it suits our goals. When it starts to go sour, we’ll dump it and pickup another one that looks promising. We’ll keep doing this until we find the one that will take us where we want to go. We’re ambitious and we don’t want to spend 40 years doing the same thing over and over again. We don’t want to pay dues to earn a retirement.

We want to work for fast moving start ups and we want to work hard to help it succeed. Want to know why? Because there’s usually freedom, growth and excitement! They want talent and they find it, use it appropriately and reward it accordingly. What are your employees excited about?

Now, I know you’re still confused. So I’ll sum it up: You should do everything you can to make sure your employees are happy and their needs are met. You think that you can throw money at us and we’ll settle down. That doesn’t work anymore. If it does work, it’s only a band-aid. We want to work from home (or Starbucks), we want to be comfortable while we work (clothes, music, work space), we want flexible work schedules. There’s no reason why we can’t have any of these. It doesn’t hurt productivity at all.

Realize that we’re all different in our own ways and you can’t force us into changing just because you have a CEO that’s 80 years old and he still thinks it’s the 50′s. Learn to utilize us in the way you need without restricting us to a point where you get nothing.

Do I speak for everyone? Nope. There are those who want to do the bare minimum and not make waves. There are those who will do what ever you want to make sure they get their pay check. Is that what you really want though? Something to think about.

Standards & Best Practices – Creating Consistency

Disclaimer: You and your team may not suffer from the issues described here. If not, hats off to you! The following recommendations are just that, recommendations. They are techniques I’ve used and they worked. Use them as I describe or as a template to for you own solutions. It isn’t about being right or wrong, but being consistent. If you have a well functioning team, I’d love to hear about how you do it so please write me.

This is the first post in a series of unknown length. Even though I do have a structured document that I deliver to my teams, I don’t plan on following any specific path with these posts. The topics will most likely jump from post to post as I see fit.

In this post I want to talk about consistency. Every company I’ve been to has had this same exact problem. Development teams are fragmented (e.g. skill level, understanding of concepts/technologies).  The two biggest issues I see with dev teams have are with vocabulary and tooling. Everyone has their own definition of what a ‘Model’ is and each one has their own favorite ORM.

Vocabulary

This might seem silly. It might sound outright stupid but it’s a common problem and it’s also a productivity killer and cause of code related problems. Even I have been a victim of this. I was discussing a problem and potential solution with a team member. We were going in a loop and getting no where except frustrated. I was about to just give up and walk away when I realized something. He was talking about the same thing I was, except he was using a different term. I asked him to define his term and the definition he gave me was the same definition for the term I was using. Had we both used the same term with the same meaning behind it, we would have come to an agreement and saved 30 minutes of frustration. The argument may as well have been,

“I agree!”
“No, I agree!”
“Nuh uh, I agree!”

Another issue with vocabulary is management!!! They love to use words they think they understand but really don’t. This leads to confusion all around, with us and them. It’s a lose-lose situation.

How to standardize

Create a list of terms and their definitions. Pass it around to the team and have them review it, discuss it and make changes/additions based on feedback. The key here is not for technical accuracy, only to bring everyone up to the same understanding so that there is no longer a language barrier. Once everyone agrees on which terms mean what, stick to them!

You will need two (or more) lists:

1. Generic development terms. For example, the list might include technology stack specific terms like Model, View Model, Entity, etc. Be sure to define acronyms as well, “DTO, MVC, MVP”. Make the judgement based on your team, but don’t assume that just because you’re all seniors that everyone understands what a DTO is.

One big problem I deal with when it comes to management is that they don’t use the correct terms for the deployment process. They consider QA the same as Dev, and UAT the same as Staging. It causes so much confusion all around for all teams.

2. Project specific terms. For example, if you’re building an invoicing system, you will want to define terms like Quote, Order, Purchase Order and so forth. Building this list of much like building a Domain Specific Language. It’s especially important when there are industry specific terms that might not be known to everyone.

Recently I was talking to my team about a project. We were talking about a Coupon. The problem was a coupon can be digital and/or paper based. But no one was in agreement on if a digital coupon and a paper coupon should be treated as a single coupon with different states or if they should be treated as different types. Some treated as a state and others as a distinct type and the end result was a nightmare. Workflows were not compatible, nor was persistence. Had “Coupon” been defined before hand, we could have avoided arguments and code rewrites.

Be sure you define not only what a term CAN be but also what a term CAN NOT be.

Standardizing common and uncommon terms will improve communication and can be shared with management and stake holders alike. It also makes developer on-boarding easier.

Tooling

No matter what problem you’re trying to solve, there will be no lack of tooling. Developer A loves Entity Framework while Developer B came from a Java background and prefers nHibernate. Who is right and who is wrong? Neither! All tools have their pros and cons and I’ve seen projects fall on their face because the original developer wanted to use tool X and he was the only one who knew how to use it so the next developer comes in and says, “We have to rewrite! He used tool X and he was an idiot!”. Projects are bound to be late or fail in this scenario.

How many times have you gotten into an argument with a developer about which tool to use? It’s ridiculous! It’s one of the worst arguments you can have. It’s just a pissing match.

How to standardize

Define the type of projects that your company will work on (e.g. web, mobile, desktop, reporting, etc). Then for each problem area, create a category (e.g. Web front end, web back end, data access, caching), then list the tools that will be used to solve each problem area. Sometimes you’ll end up with two or more tools that fit the need and that’s fine. Be sure to specify which tool to use when.

Pass the list around, get team consensus and work out any disagreements. Of course, someone will have to be the final word to prevent the infinite loop of X vs Y. Once the list is completed, enforce it!

Getting everyone on board with the tooling will reduce or eliminate the pointless arguments and will again help developer on-boarding. It also provides additional benefits to management because they can use it as part of the requirements when hiring new developers. My current company like to know what developers are using and the licensing involved along with costs.

Conclusion

The goal here is to start standardizing areas where developers like to squabble among each other to no end. Vocabulary and tooling are just the start. Standardization of processes (e.g., source control, deployment, documentation) would be the next step in getting consistency among the team(s).

Alternative to Captcha

In a recent meeting with stake holders, they were concerned about bots auto filling a registration form. The obvious answer that came up was to add a Captcha. The response was something along the lines of a groan + gurgling sound, or in real words, a disapproval. Captchas are more often than not complicated and they are always a PITA!

A long time ago I had to solve this problem and came up with an alternative to using a captcha. So I suggested my solution and it was well received.

The idea is that we want to protect from bots automatically filling out a form and submitting data but also to not bother the user with squiggles and unreadable images. Especially since the target audience is less than tech savvy and most will be older users.

It’s common for bots find fields with common names such as FirstName, Phone, Email, etc. by parsing the HTML or some how working with the DOM. There is no reason that we as developers have to use those names when building our forms though.

The idea is to add a field armed with a common ID such as ‘FirstName’, but it won’t be used for input. In fact, it isn’t even shown to the user. Theoretically, a bot auto populating the form will enter a value thinking it’s a FirstName field. On form submission, we can test the field for a value and if it has one, then obviously the form wasn’t filled out by a user.

Example form:

<form>
        <input name="FirstName" style="display: none" />
        First Name: <input name="XYZ" />
        Last Name: <input name="LastName" />
        <button type="submit" ></button>
 </form>

You can modify this a bit to fit your needs of course. This was just a simple example. Now user aren’t bothered with captchas and it will prevent [most] automated form submissions.

Cons:

• Not all bots work in the way described
• Can be worked around without too much effort
• Legitimate automated form population tools may fill in the field causing a false positive
• May cause issues with screen readers

A modification to this is the check the field value on the client side and if necessary, require explicit verification (which should include a friendly message to the user). This helps the false positives from preventing legitimate users from continuing.

It isn’t fool proof, but it is an easy alternative to confusing captchas. Other alternatives include asking the user a question and requiring them to enter an answer such as, “What is 2+2″.

The point here is to think in terms of automation and how it would work against you, then simply side stepping it instead of building a giant fortress wall.

What do you think? Do you have any captcha alternatives that you’ve used? What are they, how do they work and what was the success rate?

Building extensible applications with MEF

My new course on Managed Extensibility Framework has been released. If you want to learn MEF, give it a try. Don’t have a Pluralsight subscription? Let me know and I’ll help you out.

BTW: I’d appreciate any feedback you have. If it sucks, let me know (but include a reason).  If you don’t tell me it sucks, then it’s your fault I keep sucking :D

Building Extensible Applications with MEF
Managed Extensibility Framework is Microsoft’s answer to the extensibility problem. This course dives into MEF, its mechanics and how MEF can be used to build flexible, pluggable applications.

http://www.pluralsight-training.net/microsoft/Courses/TableOfContents/mef

Development Standards & Best Practices – Introduction

In the last three companies in which I’ve held position, I’ve not once seen any consistency across the development team. Each time I’ve started a new position, I came with the presumption that the “team” was on track and had their stuff together and I was always ready to learn something new. Nope. Teams have been disorganized, fragmented and mismanaged. Apparently this is a common theme. I’ve actually only seen one team (small, five people) who actually had their stuff together, but that was because they were employing a radical technique (which I found intriguing btw).

My current position is no different. It’s like the wild west and everyone has their own homemade guns and law books. Thankfully there is awareness by upper management that something had to be done to rein in on these cowboys. So when I came on, I proposed standards and best practices policies and training. They were all for it and I had my management buy-in!

Development is like driving. Everyone has their own style of driving; some drive fast and some drive slow. Some don’t use their friggin’ blinkers and some do. But, as drivers, we all have a set of rules we have to follow that were set forth by an authority. When you get in your car and head to work, you know that you have to drive on a certain side of the road. You know that you have to stop at a stop sign and speed up when the light turns yellow (just kidding). We all follow these rules and it makes for a consistent driving experience that allows everyone to arrive at their destination safely and consistently.

When you go to another city/state/province/whatever, you don’t have to relearn any rules. You know that you have to still drive on a specific side of the road. As developers, the on-boarding process can be excruciating trying to learn how other developers work, think and write code. Usually it’s painful because you either have to lower your standards to work with less skilled developers or you realize that you’ve been writing junk this whole time.

What I’ve proposed for the dev teams here is a set of standards that apply to a wide range of topics. Some of them are industry best practices or at least de facto best practices. Some common sense, and some are just the way I think would be best for this environment. After a three hour training session, the material was actually well received and it opened some eyes. Some developers were excited to be learning and some were the equivalent of grumpy old men who refuse to learn how to work an iPod. But it doesn’t matter. Everyone had a chance to give input and shape the way things are done.

Because of the acceptance of the material by this diverse team and the realization that so many other dev teams suffer from the same ailments, I’m going to be doing a blog series on the material I created for standards and best practices. I’ll cover topics ranging from code, check-in policies and how to divide the team up into specific roles.

I’m probably going to be ridiculed on somethings, but that’s ok because I’m always willing to learn. You can choose to accept the material or ignore it. But at least it’s out there for teams to get a hold of. It’s working here so it can work somewhere else.

If your team is super awesome, I’d love to talk with you/them and get input and insight to how things are ran there. Otherwise, use the content in the forth coming posts as a template.