The Comprehensive Guide to App Feature Selection : Questions Only

A Simplified Look

This excerpt pulls the actual questions from The Comprehensive Guide to App Feature Selection. All context and supporting descriptions have been removed. If you are a first time founder, I suggest you view the full guide. If you’re looking to work through the questions without pages of educational resources, this should serve you well.

Framing Questions

What’s the current status of the app?

  • Just Dreaming.
  • Actively Planning.
  • Live and Iterating.

What stage software are you building?

  • Prototype.
  • Minimum Viable Product (MVP).
  • Full Product.
  • Enterprise.

Who is your target user?

  • Consumers
  • Businesses

Is it downloadable from an App Store?

If yes to App Store, what platforms does it support?

  • Android
  • Apple iOS

Which mobile devices are supported?

  • Wearable
  • Phone
  • Tablet

Are there offline capabilities?

Are there push notifications?

Is there a web interface?

Which devices are most common among users?

  • Phone
  • Tablet
  • Desktop

Are there desktop notifications?

Do users sign in?

How do they sign in?

  • Username
  • Email
  • Facebook
  • Twitter
  • Instagram
  • Linkedin
  • Google
  • Slack

Are there tiers of users?

Do users have profile pages?

Do users collaborate with one another?

Does the app handle money?

Do you charge users?

How do you charge users?

  • Upfront.
  • Subscription.
  • In-app Purchases.
  • Advertising.

How is money transacted?

  • Card
  • Bank Transfer
  • Digital Wallet

Who is your Payment Processor?

Do users transact with you directly?

Do users transact with each other?

Are refunds handed in the system?

If your handling refunds, are you expecting partial refunds or just full refunds?

Which currency is permitted?

  • USD
  • International
  • Crypto

Does it contain social interactions?

Which social interactions are included?

  • Follow / Unfollow
  • Friend / Unfriend
  • Comments
  • Reactions

Does the system use email?

How does the system use email?

  • It sends emails
  • It receives emails
  • It sends and receives emails

Who is your preferred email service provider?

Does the system use text messages?

How does the system use text messages?

  • It sends texts
  • It receives texts
  • It sends and receives texts

Who is your preferred text message provider?

Does the system use phone calls?

How does the system use phone calls?

  • It sends phone calls.
  • It receives phone calls.
  • It sends and receives phone calls.
  • It facilitates the connection between people or groups.

Who is your preferred text message provider?

Do users rate or review?

Does it use GPS or location services?

Is there messaging or chat?

Is there search functionality?

Is there sorting and filtering?

Are there reports on app data?

Does it uses images?

Is there image uploading?

Is there image capturing?

Is there image editing?

Does it use video?

Is there video uploading?

Is there video editing?

Is there audio recording?

Is there video streaming?

Does it use audio?

Is there audio uploading?

Is there audio editing?

Is there audio recording?

Is there audio streaming?

Is there file sharing?

Is there data importing?

Is there data exporting?

Are changes and edits tracked?

Does it communicate to other hardware, other than the device?

Does it integrate with other services?

How many other services does it integrate with?

  • 1–2
  • 3–5
  • 5+

Is there an activity feed?

Is there a content management system?

Does it use machine learning or data science?

Does it use any virtual or augmented reality?

What level of security is needed?

  • Best Practices are sufficient.
  • Air Tight
  • Fort Knox

Are you handling sensitive personal information?

  • Medical Information
  • Social Security Numbers
  • Bank Account Details
  • Legal Documents

What are your expectations on app performance?

  • Quick enough to be enjoyable
  • Very Fast
  • Blazing Fast

Does your team handle hosting?

Does your team handle maintenance?

Do you have terms and conditions?

Which categories best describe your product?

  • Fundraising Platform
  • Social Media
  • Ecommerce
  • Analytic Tools
  • Calculator
  • Marketplace
  • Smart Home
  • Project Management
  • Automation

Which programming languages are used?

  • No preference / Not sure
  • Ruby on Rails
  • React
  • Angular
  • Python
  • Java
  • Php
  • Javascript
  • Swift
  • Objective-C
  • Other

Which parts of the process do you need help with?

  • Strategy
  • User Experience
  • User Interface Design
  • Software Engineering and Development
  • Launch and Deployment

New Year Ritual : Change Your Passwords (plus checklist)

In recent years, we’ve seen massive data breaches come across the headlines. Unfortunately, these reports represent a small percentage of the actual infractions. While our data is only as secure as the people entrusted with storing it, passwords are the first line of defense. Taking an hour or so once a year to update your most commonly used accounts (or as many as you can remember) could safeguard your information.

If you’ve been waiting for the right excuse to start using a password manager like 1Password or LastPass, a systematic password refresh would be great option. You could generate large, highly secure passwords and store them in a safe place.

Below is a quick checklist of common passwords you’ll likely want to reset. There are also great tools to help configure more secure passwords.

Personal Accounts

[ ] Banking Institutions

[ ] Credit Cards

[ ] Insurance Provider

[ ] Personal Email

[ ] Personal Website / Blog

[ ] Amazon

[ ] Facebook

[ ] Twitter

[ ] Instagram

[ ] LinkedIn

[ ] Youtube

[ ] Quora

Business Accounts

[ ] Business Email

[ ] Payroll Service

[ ] Invoicing Service (Xero, Quickbooks, Freshbooks, etc.)

[ ] Project Management Tool (Basecamp, Asana, Trello, etc.)

[ ] Communication Tools (Slack, GroupMe, Hipchat, etc.)

[ ] CRM (Salesforce, Hubspot, Campfire, etc)

[ ] Email Marketing (MailChimp, Constant Contact, Customer.io, etc)

[ ] Marketing Automation (PersistIQ, Mixmax, Salesloft, etc)

[ ] Form Submission (Jotform, Wufoo, FormStack, etc)


If you’re a security minded individual and interested in other tools to tighten up your digital diligence, here is a list of helpful privacy products.

One Key Metric

“How should I measure my improvement?”

 
It’s a common question I receive from Apprentice and Junior Engineers. For those focused on growth, they often search for a metric to track their improvement over time. 
 
How will I be graded? What should I optimize for order to improve? How do I know I’m improving fast enough?
 
In software, ‘number of code commits’ and ‘lines of code written’ seems obvious. for early stage developers. It’s trackable and big numbers give the impression of progress. Unfortunately, code quality is not measured in quantity and volume. In fact, there is often an inverse correlation.
 
The question originates from a positive attitude, but the answer is complex and past attempts at oversimplifying have proven disastrous. There are stories of incentivizing engineers by ‘bugs found’, but that sparks the temptation to neglect proper troubleshooting up front. Incentivize overly-concise code and you may lose clarity. Champion lines written and things become verbose and bulky.
 
Reluctant to ignore a challenge, I sought out to answer the question. If an aspiring engineer were to focus on one key metric to drive their growth, what would it be?
 

Quantity and Quality

 
There was once a college professor working with a group of photography students. He divided the class into two groups and ascribed unique grading to each. Group One would be graded on quantity of unique photos. Group Two would be graded on quality of their photos.
 
In the end, the group of student who focused on quantity actually had the highest quality as well. They tinkering with lighting, unique subjects, and diverse settings. This resulted in better work over time. The quality focused students toiled longer per shot. They overvalued each interaction with the camera.
 
The moral for software engineer is not to write more lines of code. Instead, the focus on quantity should be around consecutive days. How many consecutive days can you try to apply the skills and techniques I’ve learned? Continual, deliberate practice. 
 
As I look back over years and millions of lines written, consistency has been my greatest strength. Early on, I was writing software every single day. Even if for a few hours, I was putting in the time to polish and refine my craft.
 
The idea came from my cross country coach. He would remind us that every day you skip a run, you loose 10% of your training. You slow the momentum and miss the opportunity for the effort to compound. He may have been wrong, but the idea anchored in my mind. I could sense the ‘ramp up’ time on Monday was longer when I would neglect Saturday and Sunday practice.
 
I later learned this was the exact approach Jerry Seinfeld used when coming a comedian. He had a calendar where he put an ‘X’ each day he practiced. The only goal was to not miss an ‘X’. If you miss once, don’t make the mistake of missing twice in a row.
 

Let your mind rest

 
To be clear, I’m not advocating for endless hustle and grind. Your mind certainly needs time to rest. Every day doesn’t need 8+ hours of heads down time. That’s unrealistic and ill-advised. However for less experienced professionals, longer gaps require more time to get reoriented. 7 days spent working 4 hours is far more impactful than 5 days working 6 hours. Adding up the hours is misleading. The consistency is what leads to the greatest impact.
 
I would encourage you to use the grid on your Github profile to track your progress. Early on, my goal was ‘no white squares’. That means I would need to write at least one commit worth of code per day. That’s it. I found myself doing more, but there was no bonus for more commits. That starts incentivizing the wrong behavior.
 
If you want to get better, it will take time. There is not path to meaningful, overnight success. Buckle in and keep showing up.

Building a Marketplace

Over the years, we’ve built plenty of marketplace solutions. Unlike feature based or business management software, the value of the technology within marketplace software is in the relationship that is facilitates. The most common formation is a two-sided market place. Two-sided marketplaces connect a seller and a buyer. Examples we’ve build include connecting law firms with project attorneys, job seekers with employers, riders with drivers, or even brides with wedding vendors. Two audiences exist and the software becomes the match maker. Their interests are align, they just need to be connected.

Two-sided Complexity

Two-sided markets have inherent complexities. A common complexity is around value. Once the match is formed, what keeps the customer and vendor within the system? Airbnb, for instance, matches renters with home owners. Since the behavior involves real world interaction, the two parties could conduct business offline in future interactions. It becomes the goal of the marketplace to add value beyond the matchmaking. In the case of Airbnb, the leverage renters insurance. If you skirt their system, they reserve the right to decline all claims if anything goes awry.

Craiglist charges certain markets for simply creating the listing. They expect you to handle financial transactions off system, but charge the vendor. Interestingly enough, Craigslist only does this in a few cities. Charging vendors in a small number of cities produces enough revenue to make it free for everyone else, which continues to increase adoption.

Match.com is another fascinating example. When they fulfill their stated purpose, helping people find love, they actually lose a customer. Once you’ve entered into a happy, healthy dating relationship, their service becomes less valuable to it’s users. This tension can create a reverse incentive for the marketplace.

Triple the Chaos

Two-sided markets are complex, no doubt. But what’s more complex than a two-sided market? A three-sided market. That’s right, three audiences each coming to the table for a piece of the value-equation. In a three-sided market, the market software becomes the referee. The marketplace is responsible for maintaining the delicate balance of everyones’ best interest.

Imagine a triangle. The strongest form of a triangle is one in which all sides and angles are equal. A solid market with three parties should maintain a similar balance. If one party senses misalignment, it becomes more advantageous for them to leave. Over time however, the balance tips as each party pushes for their best interests.

Take recruiting firm for instance. Job candidates sign up, employers post jobs, and recruiters access the candidate pool to fill positions. Recruiters, compensated on a percentage of the employees salary, are incentivized to pursue high salaries for employees but only for those willing to pay either commission. Employees, incentivized to find the most purpose filled, flexible work at the best pay, field as many options as possible to make sure they find the best one. Meanwhile, most employers want to keep the process short, hire at-or-below market, and find someone who fits their values. Their interests overlap, but clearly conflict along the way.

Defining the value and continually communicating it to each party is essential to maintain equilibrium.

Chicken or the Egg

Whether the market has 2 or 3 sides, a chicken-and-egg scenario quickly forms. Imagine trying to use Uber without enough drivers. It doesn’t work. How about enticing drivers without anyone to drive? The marketplace depends on having enough people on both sides of the relationship.

Fortunately, we have noticed a trend. It’s easier to get the vendors than the customer. The audience who stands to gain financially is easier to build, so start there. We have speculated on why this might be, but it’s important not to overcomplicate it. The one who is making money is more likely to show up than the one you’re expecting to spend it. Eventually you will need the other side of the market but we’ve seen great value in moving fast and confidently building the list of sellers first.

Start Simpler

Building marketplace technology is complicated enough, don’t add unnecessary weight. Starting simple to prove the concept and validate the value will save time, money, and headache. I shared recently about starting smaller, which includes insight into a 3-sided marketplace. The big takeaway was how effective a simple email blast proved to be. No fancy software or complex system, but a simple touch point that connects key audiences at a consistent interval. Find the smallest measurable step and get started.

In the end, you should expect a 4-5x increase in complexity when building a marketplace. There are unknown technical constraints and instability in the increased human element. There are more variables than a service based business or a suite of products, so you’ll have more people with misaligned interests. Choose wisely. If you imagine an elegant three-sided market, push yourself to start with two. If you’re planning to invest in a two-sided market, figure out how you can validate with half the market first.

Entry Level Engineers Cutting Their Teeth

I found myself drawing a distinction between code school graduates and Junior Engineers. It’s not to diminish the effort or credibility of code school. It is to elevate the importance of real world experience. Deploying to production software is key to the Junior Engineer distinction. Beyond a brochure site or public facing test app, a Junior Engineer needs time spent on a system with daily active users.
Realizing it’s often hard to get the opportunity to work in a live environment, our apprenticeship is designed for Entry Level Engineers.

What do you look for in an apprentice?

This is by no means a comprehensive list, but we have found patterns that define solid apprenticeship candidates.

  • Proactive learner. Pursue a deeper understanding rather than waiting to be tasked it.
  • Action oriented. A default to ‘jumping right in’ rather than waiting for complete clarity.
  • Inquisitive. The ability to ask good questions and digest the answers.
  • Curious. Not just wanting to make it work but interest in understanding why it works.
  • Consistent improvement. Continually putting in the effort and learning from past mistakes.

What is most important skill to prioritize?

A disciplined approach to version control. We call it git chops. Slicing work into the right sized chunks, tracking the progress effectively, and issuing pull requests at appropriate times will go a long way. It will force apprentices to be more deliberate and focus on one feature at a time. It also helps mentors contribute more constructively to the learning process.

At the end of the day, a spirit of tenacity and thoughtfulness goes a long way in the learning process. It’s not all about hard work, but the path to proficiency is long and rewards those who stick with it.

Start Smaller

In 2016, we built a streamlined recruiter management system. It allowed candidates to connect via LinkedIn, recruiters to post jobs, and employers to filter prospects. The interface was clean and polished. The value was well defined and benefits were obvious.

For months prior, the client also had been working to build an email list. Every week a newsletter would be sent to job-seekers with top jobs in the industry. Employers would also receive an email with top candidates. It was basic and simple.

Engagement

In the end, their email list was 30x more effective at connecting people to jobs. It wasn’t much, but it worked. It wasn’t sexy, but apparently it didn’t have to be. When he approached investors, they couldn’t reconcile investing in an app when the traditional email was working well. “Comeback when you have a plan that capitalizes on the effectiveness of that email list.”

The technology was not the answer. It was about engagement. What did people actually use?

The early days of New Story, it worked much the same way. Instead of waiting until a revolutionary new platform was ready, one of the founders hacked together a few tools in order to prove the concept. They used a third party donation service. The progress bar had to be updated manually. Each “campaign page” was built from scratch. In light of today’s robust system, it’s nauseating  to consider the amount of manual work that must have been involved. It wasn’t amazing, but it was good enough.

When trying to identify what the market wants, it’s worth starting small. There is always time to get bigger and more complex, assuming you can survive long enough to build something people want.

Estimating Completion via Hill Charts

In high school, I ventured out with two friends to hike on the Appalachian Trail which stretches from Georgia to Maine. The plan was to hike for 5 days, covering about 75 miles. The distance would have covered the entire section within Georgia. On Day 3 a massive mountain was expected to be the highlight of the trip. Looking at the map and using some rough calculations, I estimated we would eat lunch atop the mountain in a few hours. We’d heard from others that it was one of the state’s best views.

As you might guess, I was wrong. Ascending the mountain took twice as long as expected. Conditions were rough and visibility was poor. We were exhausted by the time we reached the top and our lunch was devoured hours before. A thick fog left us with mere inches of visibility. No view and no highlight. From the summit, we made fast work of the descent.

Estimating is hard.

When it comes to project based work, estimates for tasks and deliverables are even harder. With changing expectations and unknowns, predicting requirements to ‘get the job done’ can feel like an impossible task. The difficulty intensifies when you consider that progress is not linear. If the project lasts 10 days, it’s unlikely that you are 50% complete on Day 5.

Complexity is Misleading

If complexity is front loaded, it may have progress slowly at first but is now picking up speed. Building software often follows this trend. If you plan early, later development goes a lot faster.

When complexity is backloaded, the early days may be smooth sailing though the majority of the progress lies ahead. Hiring new team members often works like this. You may communicate with, pursue, and interview a large number of candidates, though in the end all the value is in the offer being excepted by a single candidate.

There are also certain tasks that create bottlenecks for progress. If you are 20% complete but may not have the 1 necessary piece of information to move on.

The Hill Chart

Imagine you are hiking. At the beginning of the day you start at the base of the mountain. Over the course of the day you plan to summit and walk to a destination on the other side. Unless you have hiked the mountain before, it’s unrealistic to predict how long it will take you to walk down the other side. Until you reach the summit, more information is still needed.

Projects work much the same way. There are tasks you’ve done 1000 times before and others tasks that require more clarity before estimating.

In order to clarify the process and help the team visualize where things stand, our thinking has evolved. Rather than tasks being perceived as equals, they’re plotted on a hill. Items on the left require more information and insight. Items atop the hill have a path forward that only lacks execution. Items on the right done done.

When work is plotted in this manner, the conversation changes. Instead of broad questions about completion percentages, a helpful dialogue can exist around the items that need to move up the hill.

At the beginning of a project, it’s customary for some tasks to be on the far left while a few start at the top of the hill.  Throughout the project, tasks are regularly reorganized, discussed, and shifted. Since their place on the hill speaks to different constraints, discussion is allocated more appropriately. An incomplete item at the top of the hill is vastly different than an incomplete item on the left.

Strategy Feeds Execution

Strategy is among our most valuable work. In technology, it’s easy to get caught up in apps, features, and how it looks. We must consistently stop and consider if we are building the right thing. As I look back over years of building products and millions of times of code, my proudest moments involve software we avoided having to write. In contrast, the greatest disappointments involve a tremendous amount of time, energy, and effort spent on something that was ultimately wrong.

It comes back to strategy vs execution. Doing the work or deciding on the work to be done.

Great technologists are able to align technology with business objectives. This alignment shouldn’t only be at the beginning of the project. It must happen over and over as conditions evolve. This is typically the role of the technical cofounder on smaller teams and Chief Technology Officer within large or growing organizations. Building great software is important but far superior is knowing what is appropriate to build.

To illustrate the point, it’s worth exploring a few tradeoffs. Common tradeoffs include expectations, timeline, and quality.

Expectations

What do they think they are getting? Assumptions are easy to make and hard to articulate. The phrase Minimum Viable Product, for instance, is riddled with assumptions. We all have different definitions of minimum and viable.

In the end, ‘expectation minus communication, equal frustration’.

Timeline

When will it be done? The larger the project, the harder it is to predict. There is also an assumption that it has been clearly defined as to remove all uncertainty or confusion, which is rarely the case. Time is the most challenging constraint. It is always being spent. Whether we are planning or waiting, it is passing.

Rush through planning and the journey will contain more missteps. Take too long and the window of opportunity could close.

Quality

How good is good enough? As a child, there were times when cleaning my room took minutes and times when it took hours. The difference? Quality. Was I stuffing dirty clothes under the bed or cleaning, folding, and organizing them in their proper place?

Where a proper customer and market have not been identified, we’ve found quality to be less important. Without knowing who you’re optimizing for, it’s impossible to truly hit the mark. If building for existing customers, it’s worth the extra time and attention to get it right.

Continual Realignment

Historically, Strategy Sprints preceded each project. The tension emerges when constraints change while the work is underway. Is time spent adjusting based on new information or pushing forward on the given path?

You wouldn’t plan a road trip and jump in the car without a GPS or map. Strategy is a perpetual pursuit. Constant recalculating is crucial to long term success. For engineering projects, there seems to be a natural rhythm to proceeding two week at a time. Defined break-points forces pause, reflection, and reevaluation. Making informed adjustments will ensure you end up where you intend to go.

In the end, it does not matter what you’re driving, how much the trip cost, how long it took, or how you get there if you arrive at the wrong destination.

Healthy Habits for Growing as a Software Engineer

Building disciplines around lifetime learning within tech

I’ve worked hard over the years to increase my skills as a software engineer as well as the value I’m able to provide to the larger engineering community. Somethings have worked well and some have been utter wastes of time. Getting started, it’s often hard to know which is which. Outside of a traditional education in computer science, the following habits have allowed my career to grow and evolve more consistently than anything else. I’ve also had the privilege of watching them do the same for others.

• Ask great questions.

• Experiment constantly.

• Share your knowledge.

• Invest time daily.

Ask great questions.

Active listening is the greatest oversight of most academic institutions. Neither grade school nor college offered courses on being a better listener but it has become a priceless skill. The more I learn and grow, the more valuable I’ve found the experience and expertise of others. Few things will accelerate the growth of a software engineer more than connecting with skilled people and leaning on their insight. While learning from your own mistakes and failures can be effective, the path to wisdom comes from leveraging the mistakes of others.

When you meet with mentors, coaches, or teachers…

• Prepare questions ahead of time.

• Take good notes.

• Take action on what they say.

• Followup afterwards with gratitude and learnings.

Experiment constantly.

Some days, I’d spin up 2–3 new projects to try out a certain feature or approach. It was tedious at times, but incentivized me to get more efficient and deliberate. Years later, I have hundreds of projects to pull information and learnings from. About 2–3 years in, I rarely encountered a problem for the first time.

A few tactical ways I experimented:

• Find site online and tried to create it.

• Research features of a framework and try to replicate them.

• Find tutorial sites from trusted sources, Railscasts.com was a personal favorite, and don’t watch… take action.

• We said yes to projects and challenges we had all the answers to. Early on, we gave a lot of discounts and padded out estimates by 2 and 3 times what we thought it would take. This provided a safe environment to learn, while still allowing for real world experience.

Share your knowledge.

More often than not, teaching others is the best way to solidify your own understanding. Regardless of how little you may know, try teaching someone else. Whether it’s teaching a niece or nephew on something like Scratch or volunteering at a local code school, use what you know to help others.

Building a habit of sharing your knowledge keeps you sharp and reinforces the attitude that made the internet great to begin with. Most of today’s prevailing frameworks are open source tools supported by unpaid enthusiasts.

If all else fails, write about your experience. Don’t overthink it, get started.

Invest time daily.

As soon as you stop learning, your effectiveness declines. In a fast changing industry like tech, there is little room for becoming complacent. Early on, I found space time whenever I could to read, watch tutorials, and interact with other engineers. Developing the discipline early pays dividends over time. The more I’ve challenged myself to be a lifetime learner, the more opportunities have followed.

Whether you’re connecting with others, experimenting, or sharpening your skills, consistency is key. Tactical ways to make sure you’re moving forward include…

• Schedule time each day to explore new challenges.

• Schedule time each week to reflect on what you’ve learned.

• Schedule time each month to organize what you’ve accomplished*

• Challenging yourself to publish learnings will further sharpen your insight.

Waking up early is the easiest way to find time in your schedule. In recent years, I’ve fallen behind on the latest Netflix series. I have however,  launched 3 businesses and continue to invest time with New Story.

If you’re looking for a silver bullet, I have nothing for you. While your mileage will vary, the road ahead requires consistent commitment and dedication. Much like writing great software, it takes time and it’s not done in a vacuum.

May your journey be as strenuously-delightful as my own. If you’d like to followup with more thoughts and questions, email me at morgan@polarnotion.com.

Kickstarting a Rails Project

A practical guide for new Rails 5.2 projects

I love learning how others work. Hoping to glean some wisdom or insight that could help me sharpen my skills, I’m constantly reevaluating what works best. Regardless of the nature of the rails application, I’ve found the following workflow to be quite helpful. Having built my personal site on Rail 5.2, I can confirm that each gem still works and this workflow continues to be relevant.

Preliminary Notes and Assumptions

Order matters. Installing each gem in the following order optimizes for their generator workflow. A few of the gems build nicely on top of one another. Reorder at your own discomfort.

RailsCasts are old, but helpful. It’s been years since Ryan Bates published a new RailsCast or updated an old one, but the content is still helpful. As long as you can fill in the cracks between rails versions, it’s Rails gold.

This is not an environment setup guide. This workflow assumes you already have appropriate Ruby and Rails versions installed on your machine. If you’re looking for a setup manual, this is not it. Google ‘setup ruby on rails’ for help.

Getting Started

Run ‘rails new app_name -T -d postgresql’

Beginning with the end in mind, setting a postgresql database over the Rails default will make Heroku deployments a lot simpler.

Make sure to swap ‘app_name’ for your actual app name. I understand this may seem obvious, but if you’re a copy-paste-madman this may seem less obvious.

rails new app_name -T -d postgresql

Install ‘rspec-rails’

I waited too long to throw my weight behind writing tests. If you’re not there yet either, I’m not going to use this time to convince you: skip to ‘install haml’.

If you are interested in exploring or are a TDD junky, rspec is a great place to start.

Documentation: https://github.com/rspec/rspec-rails

Install ‘factory_bot’

If rspec, then use factory_bot too. Formerly known as factory_girl, factory_bot allows for the simple setup of Ruby objects for testing. Building baseline information for each object, writing tests becomes a matter of manipulating those objects, not rewriting from the ground up.

Documentation: https://github.com/thoughtbot/factory_bot

Install ‘haml-rails’

You can learn more about HAML, but suffice it to say your code starts to look more like poetry. HAML is shorthand, indentation based markup that consolidates and expedites the code you write.

Documentation: https://github.com/indirect/haml-rails

HTML to Haml Converter: http://htmltohaml.com/

Install ‘simple_form’

Simple Form extends Rails ‘form_for’ helper and adds a level of sophistication. Combined with HAML, Simple Forms keeps form lean and limits the useless repetition.

Disclaimer: Installing Simple Form after haml-rails will ensure appropriate scaffolds are also built. Failing to do so will cause the generator to continue to build forms without the ‘simple_form_for’ helper.

Documentation: https://github.com/plataformatec/simple_form

RailsCast: http://railscasts.com/episodes/234-simple-form-revised

Install ‘friendly_id’

Friendly Id allows for clean, readable urls. With the added benefits of obscuring an object’s ID and aligning more closely with Google keywords, friendly_id is a simple, powerful tool.

Documentation: https://github.com/norman/friendly_id

RailsCast: http://railscasts.com/episodes/314-pretty-urls-with-friendlyid

Install ‘devise’

Devise is a flexible authentication solution that is consistently updated and battle tested. With a vibrant community and extensions like devise_inviteable and oauth, I have never been presented with a compelling enough reason to use anything else.

You could build your own airplane to get to California, or you could just book a flight on Delta.

Disclaimer: Follow their documentation and the command line feedback after install. If you skip some steps on setup, you could experience from frustration upon deployment.

Documentation: https://github.com/plataformatec/devise

Rails Cast: http://railscasts.com/episodes/209-devise-revised

Update generator preferences

Rails generators are great, but sometimes they need to be scaled back a bit. A quick update to the config/application.rb can cut down on the clutter and reduce the amount of code cleanup required.

# Configure Generators
config.generators do | g |
g.assets false
g.helper false
g.jbuilder false
g.stylesheets false
g.test_framework :rspec
end

Documentation: http://guides.rubyonrails.org/generators.html#customizing-your-workflow 

Install ‘ahoy_matey’

Analytics for Rails. Admittedly, I discovered this tool while building out a recent Rails 5.2 project. Unlike the other gems in the list, Ahoy is a new tool that isn’t fully vetted. Having used a number of other tools over the years, Ahoy immediately overcame my largest objections to those tools.

I’m currently working through some pains around querying with Ahoy, but other than that, it has been pretty great.

Documentation: https://github.com/ankane/ahoy

Conclusion

After you’ve run through the workflow above, it’s time to start building your custom software. From here, with each new migration or generate command, the initial heavy lifting should be done.

If you have thoughts, hit me up on Twitter: @morganjlopes

If you have code related questions, tap me on stack overflow: @morganjlopes