I like to follow the community styleguide in ruby -> Style Guide
Particularly, I like the single-line class definitions rule.
It’s known that this looks terrible. No effort to clean up space:
class FooError < StandardError
end
Working with others, I see the ‘okish’ one-line version all of the time:
class SomeClass < RuntimeError; end
But I always give a silent nod to anyone that I see using the simpler choice:
FooError = Class.new(StandardError)
Again, this is all from the community style guide -> Style Guide
Splitting strings into chars is a common programming application, especially if you’re parsing a lot of text or reading line by line. Below is a couple examples from the other day I used to split strings in ruby.
file_lines = File.readlines(File.join(__dir__, "/post.md"))
# parse H1 in md
file_lines.each do |line|
line.chars[0] == "#" ? (format_h1) : (nil)
end
# remove H1 leading '#'
def remove_prefix(line)
line.shift
end
# Pop the last char
def remove_last_char(line)
line.pop
end
Nothing fancy, but useful if you were parsing markdown manually like I was. TC
Today, in this scroll happy world, I thought I’d take a second to address the trend of single page design (long form sales pages), why they work, and how to push yourself to avoid creating “micro-commitments” that separate your user and your product.
A micro-commitment is any small action that a user takes on a website or app. These micro-commitments typically move the user farther down the sales funnel. Here are a few example micro-commitments: clicks, form inputs, short reading (instructions), load-time waiting, scrolling, and any other interactions that are quick and subtle.
Keep in mind that a larger commitment of time and effort from the user is typically a conversion goal, like purchasing a product or filling out a form.
Enter long form web design. These long, scrolly pages aren’t just pretty, they actually make a ton of sense when we tactically think about web design. Consider how a user normally arrives at a home page, has to identify with a link/page, click that link, wait for a page load, then refocus their vision on the new page. With less pages, we are able to eliminate dozens of commitments that stand between the user and your conversion.
Realize that as a web designer or developer you are creating these interactions. Only you are in control of these commitments and there is no way for the user to avoid them (in most cases). Do your part and make it easier for them to connect with your product.
1. Less Micro-Commitments - It’s pretty clear, less pages in a website or app connects the user to valuable content faster and more efficiently, most of the time.
2. Intuitive Content Flow - Long form web design also causes the designer to structure information in a way that is intuitive to the users. Since the main interaction is scrolling, we can sequentially delivering content to the user. That gives the designer enormous control over the user’s experience, and it will vary much less from user to user.
3. Split Testing - Rolling off #2 - you can split-test these different architectures to find out what content flow works best. Once you identify the right sequence of content, you can drive traffic and predict results.
So to wrap this up – be anti micro-commitment driven with your design. Your products will ultimately be better if you don’t create obstacles between your user and the product. If you’re a UX developer for software, you need to consider how you can keep valuable information available at all times, on every screen, without being too busy.
With ember, angular, node, and all the other frontend frameworks for single-page apps, we’re going to see a lot more fluidity with information and users. In the next 10 years I think hardware will also contribute to this accessibility of information, allowing users to see more information at once and make decisions faster.
Woah, dude.
I’ve freelanced seriously for about 6 years, and in total about 8. Over those years, I’ve worked from hundreds of people to create, improve, or rework their online presence. I’ve found that the clients who have very clear expectations (guided by me) were the easiest to work with. It was the clients with the highest expectations (huge ROI, short deadline) that tended to be the hardest to work with and ultimately would get the least value.
Why am I telling you this?
Because as an account manager or freelance web developer, it’s your job to educate that client on realistic expecations. Now, I personally don’t like the word realistic. It just sounds average, and I don’t want any of my clients to expect average. I think the right word here is accurate expectations.
Consider this scenario. A client comes to your for a simple project, it seems feasible to complete the work in two weeks. You, an ambitious freelance web developer, bid the project accordingly and plan on working nights to beat the deadline. Piece of cake.
What you need to consider is that when you create that deadline, you are also creating an expectation. Now, the client will have an internal switch set around that expectation. They begin planning (either conciously or subconciously) around that expectation. They may have a writer get involved, or its as simple as they tell a friend the website will be done in two weeks. Regardless – the the expectation reverberates.
Well, when you get started on the project, something totally unrelated to work causes you to miss 3 days of working time. You’re behind on other projects, but it’s okay because you can work nights and catch up. A few days before deadline, you hit your first bug. Ultimately it’s going to push you back three more days. You’ve called the client and explained, but nothing will reverse the fact you failed to meet the expectation.
Every client will react differently to this. Some are willing to keep it moving and wrap the project up. You should be grateful for every client like this, and exceed their expectations on delivery. Other clients will drop you, sue you, or ultimately have a negative fallout. A lot of that is determined on their personal experiences.
You can’t control what the client has been through with another web developer up to this point. So when you create an expectation they may; A – Believe you, because they don’t have any reason not to trust you, or B. – Not believe you, because they’ve worked with freelancers who failed in the past, or C. – Have some other preconditioning like paranoia being overcharged for time based on a past conflict.
Here’s what I’m challenging you to do. Instead of bidding the projectly accurately, bid the project long and work according to the accurate deadline. Let’s consider the alternative scenario.
Instead of bidding the client’s simple project at two weeks, you step back for a second and think about what snags may arise. After thinking it through, you decide to bid the project at three weeks, and if anything goes wrong you’ll have time to fix it. When you tell the client three weeks, you receive a little discomfort up front, but the client agrees with that deadline and moves forward accordingly. You have just created an expectation.
So the job goes well, and you finish it in under two weeks. The client, in this scenario, is blown away by the fact he has an extra week to plan around his project. He actually decides to show a bunch of his friends and come back with a change list. Boom - more work, more money. You bid those changes long as well (instead of 2 days, 5 days), and you launch the project on time. Your client is happy because every expecatation was met and exceeded.
I’m telling you this because I’ve dealt with hundreds of clients in the last 5 years. Just recently, we mismanaged a client’s expectations and, although we exceeded his expectations in the product, we lost rapport by not meeting an expectation. We of course recovered this rapport by overdelivering in another area, which you should always consider when you fail.
Over the years, I’ve realized that there are certain things you need to do to push a project along faster, and ultimately make more progress than others in life and in business. Constantly focusing on these characteristics have helped me grow my business:
Constantly changing your goals and ideas is a common mistake among young entrepreneurs. My ultimate financial goal is actually the same since I read Think and Grow rich when I was 14. So that being said, stay focused, don’t be an idea jumper and create long-term progress on the idea that excites you now.
If you’re going to make moves quickly, you can’t be doubting yourself. I don’t have to get approval for every decision I make for my company and it’s important I operate that way. If I am trusted with the future growth, then I need to trust myself, too.
A lot of people take time to write down their ‘power schedule’. They’re going to start getting up earlier and getting more done in their day. They might actually get started, too. But ultimately, 99% percent of people can’t keep up a high activity schedule. If you want to see greatness in all aspects of your life, you have to be consistent.
The last thing I think have always pushed me further as en entrepreneur is my own personal standard for putting out work. Top performers and the most influential entrepreneurs work ridiculous hours and put out serious amounts of value into the marketplace. When you’re reviewing the impact of your day, where do you fall?
There are many other characteristics of the successful, but to keep this short those were the four on my mind this morning. What are some characteristics you admire in the successful?
Be great everyone.
I recently moved all of my development environment assets to a remote cloud location (Google Drive). Do you change devices often for work? Then you need to do this. After you’re done making the move, you’ll be able to:
This post is more about creating versatility and flexibility in your personal setup than anything. I want to take the time to overview how I’ve moved my personal setup to Google Drive over the last year, and why I chose to do that.
Over the last 3 years, I’ve had to purchase dozens computers/devices. That means that I’ve setup my personal setup WAY too many times. After computer 3 or 4, I moved all of my dotfiles to bitbucket/github. After an external drive blew out on me, I looked for ways to host my assets and move them seamlessly between devices. Using Google Drive’s locally hosted folders, I was able to create an efficient setup that is hosted in the cloud.
Why not? Are you going to host on Dropbox? Be my guest, but Google Drive allowed me to keep everything centralized in my business email. Google Drive also has a fantastic API, which was my other motivation. If you’re a newer developer, that won’t be a game changer and any cloud service will work.
Side Note - I developed an app using carrierwave-dropbox gem and it was hell to finish. We actualy migrated to carrierwave-aws because the Dropbox API was not awesome. So these factors contributed to my decision.
The first thing you need to do before getting started on migrating to a cloud setup is to define your assets. I needed to know what folders of mine I truly use during development. They were the following:
Ultimately, the criteria below is how i judged the success of the migration.
So starting off, the very first objective will be completed by installing your cloud host on your computer. I will be using Google Drive for this example.
Quick Overview - When you install Google Drive or Dropbox on your computer, it creates a local directory that mirrors your cloud-hosted folder. If you add a file to this directory it will update the remote location as well, creating the sync result we need.
Setting things up quickly - Migrating your setup to a new computer can take hours upon hours if you have to manually install and compile all of the programs that make up your environment. Most (but not all) CLI’s and tools for development can be installed in any folder as long as the necessary paths match up with your commands. We will act on that assumption moving forward.
What are dotfiles? - This post is not about dotfiles. But to clarify for the Jr. Dev’s, dotfiles are your personal computer config options that effect your tools. My dotfiles address zsh (my shell), vim (my text editor), and git (source control).
So to avoid reinstalling anything you to don’t have to, we move all of the files into a folder called dotfiles (this name has no signifcance, but is industry standard).
For a fantastic set of start dotfiles, check our Gary bernhardt’s dotfiles.
The only thing that is required of your dotfiles to meet our objectives, is a setup command. In my personal dotfiles, I use a rake task to create the symlinks needed to my relative dotfiles. For those that need guidance here, google dotfiles setup and you’ll get going. Rake files are a great first project for a new ruby developer that will help them understand automating tasks. In another blog post I will go into the details behind the rake tasks within a dotfiles directory.
My personal home directory looks something like this (simplified for ease, does not include Documents, Desktop, etc).
Home Directory
|_apps
|_websites
|_dotfiles
|_client-assets
|_notesFirst things first - So the first thing we need to do is represent all of these folders in the cloud somewhere. The dotfiles will be represented in a git repo, so we don’t have to put those in our cloud host.
Migrating Your Projects Folder To move your projects folder to an external cloud location, you have to look at your projects folder architecture. If you’re keeping your projects directory clean (i.e. managing them all through git and deleting folders as you finish for the day) then you won’t actually hugely benefit from this step. In our workflow, we have a ‘websites’ and ‘apps’ folder depending on the type of development we are using (jekyll vs. rail). So for me, git isn’t the only tool we use to manage our assets. Ultimately we nede to keep all of our website asssets perpetually for our clients, just in case two years later they need some changes.
Symlinks – AKA Organizational Crackrocks - Get addicted.
Symlinks are Symbolic Links that allow you to create direct links to project folders that may be nested deeper within your system.
For example, I have a friend who keeps his projects under a structure like this:
Home Directory
|_Documents
|_Web
|_Assets
|_Projects
|_ Development
|_ PHP
|_ Websites
|_ MiscWell that is CD Hell (change directory hell) if you want to navigate to that folder on a whim. More importantly, when we pair programmed, it took me even longer to get used to accessing his assets. So for the record — it is very important to have a simple, accesible projects directory if you plan on pair programming regularly.
If you don’t pair up often… then start. You’re not winning if you’re not pairing.
Symlinking Your Directories - A symlink is easy enough to create, and you can actually do it through Finder. But I would never reccomend that (death to Finder!!! pirate voice… yearrrgh).
To symlink a directory though finder, check out this link::
To symlink like a real boss, do it through the terminal:
ln -s /path/to/file/ /path/to/symlink/Now that you understand the remote host setup, and we understand symlinks, you can link everything together to migrate seamlessly. Remember, we want this to be silky smooth. What’s left?
Now that you have setup Google Drive (or an alternative cloud interface) you will be autosyncing with the cloud everytime you save a file. To make this realistic in a dev environment, you need to make those folders be simple, accesible, and high up in your directory structure. Take a look at my default structure I listed earlier to get an idea:
Home Directory
|_apps
|_websites
|_dotfiles
|_client-assets
|_notesSo for me to transfer those links to a cloud hosted alternative I need to do two things:
Here are the symlinks I used:
ln -s /Google\ Drive/apps apps
ln -s /Google\ Drive/websites websites
ln -s /Google\ Drive/client-assets client-assets
ln -s /Google\ Drive/notes notesRemember, your dotfiles are in Git. At this point, when I open up iTerm and see a new shell. If I type in “cd websites” I will see no difference between this new setup and my old setup. The terminal represents symlinks as if they are real folders, but serve the contents of the symbolically linked folder. I am synced everytime I save a file (not accounting for sync time) accesible through the Google Drive app.
So that means…
Have fun with this, and make sure your sh*t is accessible. In the words of a very, very wise person…
AINT NOBODY GOT TIME FO' DAT!!!Take care.
Your personal programming environment is going to determine a lot of factors in how your work as a web developer. When someone showed me the terminal (and jekyll) my life profoundly changed as a developer.
In this post, I’m going to walk you through the key components of what I belive contributes a strong personal environment setup. This is not meant to detail my personal setup, but instead talk about the key concepts in any environment that should constantly be refined, tested, and improved.
I was an entrepreneur first, web developer second. So when I first start building websites it was in notepad and then eventually in Dreamweaver. From 2005-2011, I used dreamweaver. I dragged and dropped files in FTP. I accidentally deleted half of my website. And I NEVER used a CMS. I only built websites page by page.
Why would I do that?
Because you don’t know, what you don’t know. Which brings me to my first component of a powerful personal setup.
It’s important to actually know about every key component in your environment. Developers need to see their environment as a toolkit that they can improve and expand. it’s like a video game — a new gem is like leveling up or geting a new weapon. Go out and start understanding the tools you have at hand and building your enviroment toolset.
Your entire environment needs to be setup to move between multiple machines. Let’s be serious - your entire install needs to be hosted in a git repository online AND you need to have a rakefile to automate the setup. If you are required to login to someone else’s machine each day to work, you need to be able to setup your environment in less than 30 minutes.
One of the first things I’ll be able to understand about another developer when I look at their environment setup, is what they work on the most often. Because if this developer works smarter, not harder, they will have shortened up the most common tasks they use with aliases.
Aliases are a ubiquitous tool across editors, shells, and computer software. If you’re not using aliases to customize your setup so that it matches you and your thought process…. well then the computer is using you and it should be the other way around.
I think a really great personal setup makes programming fun and engaging for the user. You may have noticed… there’s people with opinions in this industry. Be proud of your setup and form your own opinion on the right way to do things.
Happy Coding.