Tips n' Tricks Archives - Page 7 of 10 - {5} Setfive

Earlier this week, I was doing some work on a project that was using Twitter Bootstrap and was exclusively using Glyphicon icon set that ships with Bootstrap. The piece of functionality I was building basically involved allowing the user to rotate an image 90 degrees clockwise or counterclockwise. Looking through the Bootstrap icon set, there’s only a “rotate” icon which would work for the “clockwise” rotate but no analogous icon for a counterclockwise rotation.

I didn’t really want to use a custom icon just for this button and I really wanted to consistently use the “icon-*” class names that natively ship with Bootstrap. I’ve used CSS transforms in the past but I wasn’t sure if they’d work for “background-images”, turns out they actually do. In essence, what that means is that I’d be able to use the same “rotate” image for both the clockwise and counterclockwise icons. The CSS you’ll need to do this is:

And then to use it, you’ll just need HTML that looks like:

Of course, you’ll have to be cognizant that this is only going to work on “modern browsers” (looking at you IE), so if you’re supporting older clients you’ll need to mitigate that.

We use Amazon Web Services quite a bit here. We not only use it to host most of our clients’ applications, but also for backups. We like to use S3 to store our backups as it is reliable, secure and very cheap. S3 stands for Amazon’s Simple Storage Service, it is more or less a limitless place to store data. You can mount S3 as a network hard drive but it’s main use is to store objects, or data, that you can retrieve at a low cost. It has 99.999999999% durability, so you most likely won’t lose anything, but even if you do, we use produce multiple backups for every object.

One thing we’ve noticed is that some people have issues interacting with S3, so here are a few things to help you out. First, if you are just looking to browse your S3 you can do so via your AWS Console or I like to use S3Fox. However, when you are looking to write some scripts or access it from the command line it can be difficult if you don’t use some pre-built tools. The best one we’ve found is s3cmd.

s3cmd allows you to list, update, create, delete objects and buckets in your S3. It’s really easy to install. Depending on your distribution of linux you can most likely get it from your package manager. Once you’ve done that you can configure it easily via ‘s3cmd –configure’. You’ll just need access credentials from your AWS account. Once you’ve set it up lets go through some useful commands.

To list your available buckets:

To create a bucket:

To list the contents of a bucket:

To put a file in the bucket it is very easy, just run (ie move tester-1.jpg to the bucket):

To delete the file you can run:

These are the basics. Probably the most common uses that we see are doing backups of data from a server to S3. An example of a bash script for this is as follows:

In this script it will just output the the console any errors. As you are most likely not running this by hand every day you’d want to change the “echo” statements to be mail commands or another way to alert administrators of an error on the backup. If you want to backup more than once a day all you need to change is the way the SQL_FILE variable is named to include hours for example.

This is a very simple backup script for MySQL. One thing that it doesn’t do is remove any old files, there is no reason for this to happen in the script. Amazon now has object lifecycles which allows you to automatically expire files in a bucket that are older than 60 days for example.

One thing that many people forget to do when they are making backups is to make sure that they actually work. We highly suggest that you once a month have a script which will check that whatever you are backing up is valid. This means if you are backing up a database that it checks to make sure that the database will reimport and that the data is valid (ie a row that should always exist does). The worst thing is finding out when you need a backup that your backup failed ages ago and you have no valid ones.

Make sure that your backups are not deleted quicker than it would take you to discover a problem. For example, if you only check your blog once a week, don’t have your backups delete after 5 days as you may discover a problem too late and your backups will also have the problem. Storage is cheap, keep backups for a long time.

Hope s3cmd makes your life easier and if you have any questions leave us a comment below!

Earlier this week, I was catching up with a buddy of mine and we started talking about some of the custom workflow tools we’d built for his sales team. From an engineering perspective, these tools are fairly straightforward – things like scrapers, browser extensions, and simple crawlers. What was interesting, was listening to how much of an impact simple tools like this were having on my friend’s sales team. From decreasing “grunt work” to helping them surface high quality leads, it started to become clear that the tools were generating high business value relative to their development costs. As we were chatting, I started to synthesize what seemed like the three key reasons the sales guys loved the tools.

Cut down on “grunt work”

Most people hate grunt work, but salespeople have a special disdain for it. They would much rather be on the phone selling rather than scraping data off a website, entering it in Excel, and then seeing if some formula decided they had a worthwhile prospect. Apart from being a waste of time, repetitive menial work kills morale and artificially limits sales bandwidth. By building tools to automate these processes, we had unknowingly helped keep the team motivated while also letting them do more selling and less bitch work.

Help reduce information asymmetry

As a naivete observer, my impression is that in many instances high volume sales people enter the sales process with imperfect or incomplete information. Often times, the information they don’t readily have is public but they lack tools to make the data easily available. From straightforward examples like knowing an employee headcount to more technical ones like knowing what hosting provider a prospect uses, these data points can often help shape the pitch to ultimately win the sale. After chatting with my friend, custom tools effectively fill this space since they’d offer unique insights compared to off the shelf solutions.

Nurture experimentation

Stagnation is a common problem across every job function. Once processes are set, it becomes the same daily grind and its difficult to justify any need for change. However, in my experience introducing new tools gives the organization the impetus to try out new things and hopefully pushes the envelop forward. There is clear precedent for this in software development and I’d argue the same holds true for both sales and marketing. Given new tools and room to explore, motivated people will buck the norm and try something new.

At a high level, I think developing custom tools for any job function is a worthwhile investment and it sounds like some of our sales tools have had a measurable impact which is awesome. I’m now off down the Quora rabbit hole in search of additional insights and anecdotes….

Yesterday, Daum and I hung out at HackHarvard and gave a presentation about how we started Setfive, the challenges we faced, and some of the lessons we would tell our younger selves. The feedback and resulting discussion was pretty interesting so it seemed like it makes sense to share. Some of these things are probably mistakes you have to make for yourself and 90% of advice is crap.

Don’t get bullied

Looking back, a lot of the early “negotiations” I did with clients was really them pushing me around and me accepting whatever terms they ultimately demanded. People were using veiled threats of yanking the deal, asserting that “I didn’t know how business was done”, and being overly demanding with changes and calls to manipulate the direction of the deal. In addition to professionally, I also remember several instances of real estate brokers and landlords trying to strongarm me personally. Anyway, so the takeaway has been in life or work there’s a difference between negotiating and bullying.

Don’t be afraid to say “I don’t know”

During highschool and college, I’d always been conditioned that when someone asks a question, especially an “adult”, I should obviously know the answer. Professor singles you out to answer a question? Better know the answer. Unfortunately, this feeling stuck with me into the “real world” and I had a tough time admitting that I didn’t know the answer to a question on the spot. This usually resulted in overpromising, having to backpedal later, or being stuck bullshitting through some half baked explanation. After being around the block, it became clear that saying “I don’t know, let me get back to you” was acceptable and the better move. Turns out, in the real world everyone isn’t a walking manpage.

“Big” $ numbers are just numbers

Coming out of college, the largest check I had written was for $5000 and the largest check I’d probably cashed was for around the same. Because of this, I had a hard time taking myself seriously while asking for “big” dollar numbers. After a while, I started to realize everyone has a different concept of what a “big” number is. $5,000 might be a mountain of cash to me but to someone else its just their monthly Salesforce.com subscription. Once I understood this, it became much easier to walk into a meeting and confidently talk about money.

If they look clueless, they probably are

Throughout highschool and college, I hadn’t experienced many instances where someone was trying to seriously cover up the fact that they were clueless. Over in the real world though, this seemed to start happening frequently. Initially, I had a hard time wrapping my head around the fact that the “Senior Developer” explaining his “master/master” setup was just entirely wrong. The issue with having these blinders was that it made it difficult to effectively communicate with stakeholders when there was someone bollixed in between. Once I realized that cluelessness was really cluelessness, it became much easier to marginalize the people that were lost and get shit done.

Everyone is not like you

Something that took awhile to realize was that not everyone is like me. I had a hard time figuring out why everyone didn’t “get” how to use certain websites or why everyone didn’t immediately jump on new tech products. Turns out, everyone isn’t a heavy drinking software engineer that reads Hacker News. After realizing that, it became easier to emphasize with different types of users and also better connect with stakeholders.

Anyway, these are my notes to send back to 2009. Would love any thoughts or feedback in the comments.

One of the hardest things to do when building a software product is effectively communicating your ideas to your development team. In addition, these issues are usually magnified when you’re early on in your product process. Generally, communication issues between stakeholders and developers fall into “macro details”. “expected behavior”, or “user interface concerns”.

Despite being an oxymoron, “macro details” captures the types of errors that occur at the architecture level. For example, imagine you were building a calendaring system for intramural sports teams where each team manages their games for the season using the calendar. A “macro detail” would be that each “team” owns a single “calendar”, a potential error then would be the development team coming back with a solution where every “player” on a “team” owns a “calendar”. Following from that, the “expected behaviors” of the system would capture issues like “what happens if two teams try to schedule a game for the same day?” or “can a player be on more than one team?”. A defect then would be that the stakeholders expected the system to not allow multiple games on the same day but the system allowed it. Finally, “user interface” concerns would typically encompass how the various components of the application are organized and what the different screens are.

Great, so how do you avoid these problems? What follows below is a loose framework for mitigating these issues, it certainly isn’t original but rather a synthesis of techniques that I’ve seen help power effective communication.

Oh hey, from 10,000 ft.

For a totally new product, getting started is often the hardest part. Usually, the entrepreneur or executive who is building the product has been frantically planning, talking about, and “living” the product for sometime before the project actually kicks off. The result of this, is that the stakeholder intimately knows the ins and outs of the project but the rest of the team won’t necessarily be aligned with the primary stakeholder. Because of this, starting by writing a 1 – 2 sentence “10,000 ft. view” is usually a great first step. Using the sports calendering example from above, you might end up with:

I want to build a calendaring application to allow intramural (think old man kickball) sports teams to collaboratively plan their games for the season.

Who, What, Where?

With the “big idea” down on paper, the next step is to start defining the primary objects in the system and how they are all related. At this stage, other people normally develop “user personas”, which describe typical users of the system, and then elaborate on how each persona will use the system. In my experience, this approach is effective but inexperienced stakeholders tend to get caught up in the details and ultimately have a difficult time reaching the right level of abstraction. Looking at the calendaring app, some of the objects you’d end up listing would include:

Teams
- Composed of players
- Own a single calendar
- Linked to a single league
Players
- Primary actor in the system
- Each user will be represented by a player and own a single profile
- Linked to a single team
Calendars
- Owned by a single team
- Contain games on specific days
Leagues
- Comprised of multiple teams

Anyone that is familiar with Unified Modeling Language will notice the format is similar to how UML uses nouns and verbs but its a bit different. I’ve always had better luck using natural language to write out the relationships between entities and then converting that into an entity relationship model and then RDMS tables.

Rules, Rules, Rules

Once the primary entities are defined, the next step is to write out the business logic to minimize the confusion around how the system should work. There are formal structures for this as well, including behavior driven development, but in my experience its easier to kickstart the conversation with natural language specifications and then introduce BDD later in the development cycle. Anyway, running with the example you’d end up writing out something like:

Users (Players)
- Can create accounts
- Can create games on a calendar
- Can join “Teams”
- Can’t join two Teams
Teams
- Created by “Players”
- Can’t be deleted after there’s at one member
Calendars
- Automatically created when a team is created
- Won’t allow two games on the same day
- Can’t be deleted
- Will only allow users to edit their own events/games

Like with the entity relationships, I usually start with natural language and keep the definition of “business logic” pretty loose so that I can capture as much information with the stakeholder as possible and then formalize from there.

Draw me a map

Finally, the last piece is usually communicating what the UI of the application should be. Depending on the makeup of the team, the amount of input that business stakeholders have in this respect might be minimal. However, if there isn’t a dedicated UI/UX resource available UI mockups will definitely be a valuable asset in helping communicate the vision of the application.

There’s several tools for developing UI mockups including Balsamiq, OmniGraffle and Mockflow. Generally, any tool you’re comfortable with will work fine but the key concern should be not “lowering” the designs too far to allow people to concentrate on the ideas, not the specific implementation. I’ve always been partial to Balsamiq since its attractively priced, easy to use, and the final mockups are more like sketches than a finished design.

Anyway, sticking with the calendaring project you might end up making a screen that looks like this:

Like everything else, the definition of UI mockups are generally flexible. Some people like to “lower” pretty fair to high fidelity designs and other people like to leave them at “pen and paper” type sketches. At the end of the day, it’ll be a project by project decision.

Wrapping up

Well thats a crash course, with examples, of how I generally work with key stakeholders to sketch out projects. Ultimately, figuring out the best way to communicate your vision to your engineering team is going to be a personal decision. You’ll probably end up having to mix together several techniques that take advantage of the skills on your team and match the requirements of your project.

Category: Tips n’ Tricks

Bootstrap: Can you rotate Bootstrap icons? Sure you can!

Using s3cmd to make interactaction with Amazon S3 easier, including simple backups

Tips: Why you should build tools to empower your sales team