Note To Self

Teamwork Doesn’t Have to Suck

Note: This is a repost from my Medium account, https://medium.com/@ericsaupe/teamwork-doesnt-have-to-suck-741fe1a9ec61

Let’s face it, teamwork can suck. A new project comes up, the team gets together and inevitably a small portion of the team does the majority of the work. Deadlines come, tensions run high, and suddenly you dread waking up in the morning to head back into the hell that has been created. We’ve all been there. Let’s talk about how to make all of our teams better not only for our own sanity but for every member of our teams.

Teams can be great!

Move together

Hard working team members can quickly lose their drive without a destination in sight. A common and achievable goal should be the first step to improving any team. Each member should know their role and how they contribute to moving towards that end.

“Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results.”

— Andrew Carnegie

Recently I was responsible with leading a complete rewrite of our company’s eCommerce site. The goal was simple, get us on a new open-source-based platform and clean out the crap. Over the years we had made customizations to our old open-source-based eCommerce platform to the point of forking it; effectively destroying the benefit of open-source technology. This project was our attempt at getting back into the community and “going vanilla”.

Bringing us together were the baby steps that we each made to move our large project toward the finish line. Those baby steps came from small tasks rather than large epics. Developers had clear features to implement, QA had specific guidelines to follow, and project managers had direct questions that needed to be answered. Everyone had something to contribute and because the tasks were small and clearly defined it was simple to feel like we were moving as each one was completed. After months of hard work we successfully finished the project and grew closer through our achievement.

That sense of movement, even if small, drives momentum and encourages teams. Set a goal, define a path, and let everyone run.

Cut the weight

Over the years I’ve worked on good teams and bad. The biggest team killer is a bad team member. One person can easily drag an entire team down due to their attitude, lack of communication skills, or the work they produce. The hard truth is that person has to go.

That can be hard to hear and even harder to execute. Do we just fire them? Move them to another team? Yes! Whatever it takes to get the toxic person out of your group is the answer. I once worked on a team where everyone was very communicative until this one person came around. Then everyone tensed up and were afraid to share their opinions for fear of being confronted about their ideas. This kills the team.

No organization or project is worth holding hostage over one team member. Shake it up and lose them. If it’s not working out then make that change sooner than later. The team will benefit greatly.

Build each other up

Praise never seems to come often enough. We should share in our defeats but build up individual accomplishments. When something goes wrong the team together holds the responsibility. When something goes right the individual people should be praised for their great work. This does two things to the morale of a team. First, a single person is not criticized for damaging your project. We are moving this thing together so we should share the load when things get heavy. Someone falters and we all get behind them to get everyone back on track. Second, individuals can see that their contributions are noted and matter. Even the person who may not be at the forefront of day-to-day additions should be thanked for every bit of effort given to the team.

Whatever good things we build end up building us.

— Jim Rohn

I’ve worked on projects where one or two team members contributed to a very high-profile feature that was talked about immensely while others did the less glamorous features and bug fixes. Were the latter’s contributions any less to the overall movement of the project? No, and they should be praised openly for doing their part as well as the others for the high-profile feature.

One way that we keep the praise going is using a Slack extension I created called Sticker Chart Party!. It gives your Slack team a digital emoji sticker chart similar to grade school days where we can quickly give a sticker every time someone does something noteworthy. Messages can be attached to the emoji to see why people got them and it’s a fun way to thank people for their contributions and help.

Sticker Chart Party! makes praise easy

My current team has grown closer together thanks to constantly high-fiving each other over all of our victories and banding together during the struggles. A good team should make every member feel comfortable and supported without alienation.

Small changes again and again

Iteration is key to life. Teams should always be evolving. As new people come and go the dynamic will always be changing. Open discussion should be encouraged on what is working and what isn’t and how to improve it. Tools, processes, and work styles should all be on the table for debate. If an idea is presented on making work life better by allowing for a remote work policy it should be discussed and tried. My current company just decided to go remote-first opting to allow employees to work wherever they feel comfortable that day whether it be at home, the office, or somewhere else.

Don’t be afraid to change how the team is working. I’ve seen people come in to a job and just settle into the routine saying, “That’s just the way it is here”. In all the companies I’ve worked for there is always room for change and improvement. Maybe as small as putting up art on the walls or shifting schedules around. Whatever makes the team happier will make them more dedicated and productive.

Be the change

It’s better to ask for forgiveness than beg for permission. Make your teams better right now. Be the positive change by publicly thanking those that are doing good work. Start the dialog in team meetings by bringing up possible issues that can be resolved as a group. It all needs to start somewhere and, in my experience, everyone wants to make things better and will rally around the idea of at least trying new things.

Shake things up and be happier in your teams.

rails

One of the great strengths of Rails is the ability to create layouts that house various views of content. You create a layout with a basic HTML structure and then simply drop in your new content based on the view you are rendering. One of the simplest layouts is one that just renders the view that takes up the whole page and this is accomplished by the auto generated
app/views/layouts/application.html.erb.

The highlighted line is the important one. That <%= yield %> tells Ruby on Rails that whatever view you load just drop it right there. That’s great! Now we have a simple base layout that houses our imports and basic structure and CSS and we simply drop in our own content inside of this.

Let’s say we want to take it a step further. What if we want a left and a right side bar which is unique to each of our views? We just need to change our basic layout a little bit to add those columns and then update our view template code to take advantage of our new structure.

Yield Sections

app/views/layouts/application.html.erb

app/views/MODEL/new.html.erb

Following the suggestion of Obie Fernandez and Kevin Faustino in their book The Rails 4 Way, I have placed the two named structures of the layout first. It makes it easy to distinguish what the smaller sections will contain before getting to the meat of the content. Everything that isn’t labeled as content_for will be dropped in that unnamed yield in the layout.

Render Partials

That’s all well and good but what if you don’t want a specific set of sidebar content for every single view. Maybe a shared partial for the right bar will work great. In that case you’ll need to use the render method in your template to generate the template for you. Here is the example from above but using a shared right side bar template.

app/views/layouts/application.html.erb

app/views/shared/_right.html.erb

Render Partials with Variables

You can even pass in variables to your partials. Let’s say our right side bar takes advantage of some user data. We just pass the user variable to the render with a comma and a hash type variable being passed.

app/views/layouts/application.html.erb

app/views/shared/_right.html.erb

Pretty cool, right? I hope this introduction to layouts and partials was helpful. If there are any problems with my examples or if you have any questions please feel free to leave a comment below.

install-postgresql-934-on-mac

PostgreSQL is a pretty common database choice these days. It’s quick and fairly easy to set up but a lot of the information I’ve seen online makes it much harder than it has to be so I’m going to put my notes here.

  1. Download PostgreSQL and follow the installation guide for your flavor
  2. Fire up your console and type $ psql to open the Postgres command line
    1. From here you should do all of the commands you find online
    2. Everything you find on http://www.postgresql.org/docs/ will work in the command line
    3. This will be your main interaction between you and your PostgreSQL databases
  3. Create a Database – CREATE DATABASE my_new_database
  4. Read the docs and do some Google searches to find all of the commands you’ll need. There are way too many to list here and they all have their uses.

That should get you up and running. If you are doing a web development project your web framework would probably take over from here once you have your databases created. Django would create tables on its own, especially with South or 1.7 with migrations. Ruby on Rails could create tables using $ rake db:create or for more developed projects $ rake db:schema:load.

As usual if there is anything I’ve missed or questions that you have feel free to leave a comment below.

Installing Rails on Mac OSX

rails

When developing for Ruby on Rails the first thing you’ll need to set up your development environment. This guide will be for installing things on Mac OSX and would be similar for Linux. These are my notes from experience setting up a Rails environment based on The Rails Tutorial by Michael Hartl.

New Rails Installation on OSX

Install Git

Checks if git is installed and if it isn’t it will install it

Install Ruby (Already installed)

Checks Ruby version, already installed on OSX

Install RVM

RVM is for multiple Ruby on Rails environments for different projects.

Install RVM Requirements

NOTE: RVM tries to install gcc46 which is an older version of gcc on OSX. Mavericks already has gcc installed so install the list that appears except gcc. It also can install but take a VERY long time so just be patient and see.

Tell RVM where OpenSSL is

Create .gemrc

This file stops the installation of Ruby docs, the text below goes in .gemrc

Install Rails

You should be ready to create your environment and install your Gems. If I’ve missed anything, or you have problems, let me know in the comments below and I will update this list.

ubuntu-logo14

With the latest LTS release of Ubuntu many people, including myself, will take this time to do a fresh install of the OS on their development machines.  Here are a few tips for getting up and running after your OS is installed.  This guide will be for Python and Django development using Ubuntu 64-bit, alter the commands to work with your flavor of Ubuntu.

Git

  1. sudo apt-get install git-core

JDK

  1. Download the latest version of JDK from Oracle.
  2. cd /usr/local
  3. sudo tar xvzf ~/PATH/TO/DOWNLAD/xvzf jdk-8u5-linux-x64.tar.gz
  4. sudo nano /etc/profile
  5. At the bottom of this file paste the following lines:

In the terminal type java to make sure it is working.

PyCharm

If you want to use settings from your previous install of PyCharm click File->Export Settings and back up this file to be used on your new installation.

  1. Download the latest version from PyCharm.
  2. cd ~/PATH/TO/DOWNLOAD/
  3. tar xvzf pycharm-professional-3.1.2.tar.gz
  4. cd pycharm-3.1.2/bin/
  5. ./pycharm.sh
  6. If PyCharm asks if you want to use old settings say that you don’t right now, we will do this after it is installed.
  7. Follow PyCharm instructions to finish installation
  8. Now you can import the settings by clicking File->Import Settings and locating the files.

Pip

  1. sudo apt-get install python-pip

VirtualEnv

  1. sudo pip install virtualenv
  2. Create your virtualenvs.

MySQL

  1. sudo apt-get install python-dev
  2. sudo apt-get install mysql-server
  3. sudo apt-get install libmysqlclient-dev
  4. In your related virtualenv run pip install MySQL-python

Django

  1. In your related virtualenv run pip install Django

At this point you should be ready to install all of the other packages you need.  If I’ve missed anything critical for getting an Ubuntu installation at least up to a working state let me know below in the comments.

send-file-iconupload-files-icon-ts7tteez

I have never found a good list of the default styles that ReportLab gives you when you run getSampleStyleSheet() so I wrote a method to spit them out and what they look like.  Below is that list along with the PDF output of each of the styles.  They are grouped into two categories, byAlias and byName.  Normally I just use the name but you can use either.

  • byAlias
    • ‘title’: <ParagraphStyle ‘Title’>
    • ‘h1’: <ParagraphStyle ‘Heading1’>
    • ‘h2’: <ParagraphStyle ‘Heading2’>
    • ‘h3’: <ParagraphStyle ‘Heading3’>
    • ‘h4’: <ParagraphStyle ‘Heading4’>
    • ‘h5’: <ParagraphStyle ‘Heading5’>
    • ‘h6’: <ParagraphStyle ‘Heading6’>
    • ‘bu’: <ParagraphStyle ‘Bullet’>
    • ‘df’: <ParagraphStyle ‘Definition’>
  • byName
    • ‘Title’: <ParagraphStyle ‘Title’>
    • ‘Heading1’: <ParagraphStyle ‘Heading1’>
    • ‘Heading2’: <ParagraphStyle ‘Heading2’>
    • ‘Heading3’: <ParagraphStyle ‘Heading3’>
    • ‘Heading4’: <ParagraphStyle ‘Heading4’>
    • ‘Heading5’: <ParagraphStyle ‘Heading5’>
    • ‘Heading6’: <ParagraphStyle ‘Heading6’>
    • ‘Bullet’: <ParagraphStyle ‘Bullet’>
    • ‘Definition’: <ParagraphStyle ‘Definition’>
    • ‘Normal’: <ParagraphStyle ‘Normal’>
    • ‘Italic’: <ParagraphStyle ‘Italic’>
    • ‘BodyText’: <ParagraphStyle ‘BodyText’>
    • ‘Code’: <ParagraphStyle ‘Code’>

Screenshot from 2014-03-26 12:07:45

square

AngularJS has a ton of built in directives and functions to make your app come alive very quickly.  One thing I noticed it was lacking was a built in on-enter event.  For example, if a user is in an input field when they hit enter I want it to do something, maybe not necessarily submit the form.  Luckily, AngularJS gives you the ability to create your own directives and add them into your app.  Below is a simple directive that you can add to your app that allows you to add ng-enter to elements in your partials.  Pass it a function and watch as you hit enter and that function is executed flawlessly.

That’s it.  Now just add ng-enter="myFunction()" to any element in your partial that detects keystrokes. This has helped me a ton and added a lot of easy functionality to an already great AngularJS system.  If you have any other great directives or AngularJS tips please leave them below in the comments.