Tommy Lee Software development for everyone else

Finishing your blog posts

I have about 10-15 half-finished ideas and blog posts. Each of these ideas take off in full force! Full of passion and enthusiasm, the words and ideas come easily.

Then, somewhere around the first few hours, I lose focus on the goals of the article.

The following is a small set of ideas and strategies that I use to cope with completing blog posts, and any project.

1. Prioritize Completion

We say we’ll do it on our free time, but that free time will always be filled.

We need to make finishing these blog posts and ideas a higher priority. I remember Stephen Covey’s Quadrants for Time Management as a way to decide what’s important.

Aim for Important and Not Urgent

We should categorize items like blog post Not Urgent and Important. These should be highest priority.

Set a Goal

Goals and deadlines can give us focus on what we can accomplish in a timely manner.

When we don’t have goals or deadlines, ideas such as this will be put on the back-burner.

I aim for 1 blog post a month as a goal.

2. Write for a Single Person

Think of certain person in mind when we write a post. This person who could definitely find our article useful, informational or entertaining.

Having an audience in mind reminds us on who is waiting for the article, and the kind of information to include. We can tailor our writing to this person.

This may not accommodate everyone, but that’s okay. Let’s aim for effectiveness, rather than appeal.

Technical Articles

Technical articles are usually difficult for me to pin down.

One part is trying to justify that I know the subject. So I:

  • Write in great detail
  • Argue and illustrate the subtleties
  • Get really dry on the topic

Another Part of me is writing in a way to avoid arguments, leading to a lot of:

  • Cross chatter
  • Self Arguing
  • Showing too many sides of the argument

While I enjoy expounding all these details, and being well educated on the topic, too often, I forget who is actually reading.

For tutorials, I illustrate my way as ‘a way’ to accomplish the task, with links to references or other people’s tutorials.

For more subjective writings, I try to present the other side fair enough.

3. Overwhelmed? Rambling? Reduce Scope

When we create stuff, sometimes we want to go very deep into the nitty gritty, and talk about the finer details, and subtleties.

Now to write or finish a blog post, we have to first create the universe.

Then we have an outline that is longer than anyone wants to read.

What to cut

We should only cut down our scope if it starts being unmanageable.

We focus each section down to one purpose. Maybe the entire blog post idea should be reduced down to one idea.

4. Dedicate some time!

Currently this is about the third or fourth writing session at completing this article. I try to squeeze in these blogs on my downtime, but I love not having downtime.

One of my favorite things about free-time is that I spend a lot of that time deciding what to do with the precious time.

Part of the Schedule

The lack of scheduling, and the freedom to do anything results in a whole lot of nothing.

I work on scheduling my free-time in a more rigid schedule. After work and dinner, I have a few hours to spend.

Each week, I schedule about an hour or two for the blogging and writing, and no more. Any more time spent might lead to increased distractions and slacking off for me.

No Confidence? Scared of Completing?

We worry too much about the opinions of others and their negative attitudes. We let the invisible hating peanut gallery crawl into our brain, and shake up our attempts at anything.

Then we sit around, with nothing on the screen, paralyzed by the fear of our own inadequacies. We feel that we’re not good enough, that everyone will rip us to shreds, and the best course of action is to do nothing.

Then the existential dread kicks in, and life spirals out of control, due to us trying to write a blog article.

Well, probably. That might happen.

An Optimistic Approach

Being frightened is okay. It’s something that never really goes away, but we sort of get used to the feeling of being uncomfortable. Like learning a new language, trying something new on, the natural anxiousness that arises, that’s normal.

Hey, you’re doing it. That’s a lot more to say than a lot of others. You gave yourself a challenge, and you’re fighting your way through it. That’s awesome. Look how far you came, this was a blank space before.

For me, I can have a fully rendered page and say ‘Hey I made this!’ That’s really the prize is the completion of the long road ahead.

There will be people out there that haven’t heard of your information, and will look to your piece of information as useful. It may not be until a very long time from now, but that possibility exists.

Your work will be there for someone’s One in 10,000.

A Pessimist Approach

We may have put our work too high on the pedestal. We’re so concerned about the criticism, we forget about being realistic. There’s so much content out there, what will guarantee that people read it? Most people will give it a passing glance. At least someone’s reading.

When was the last time you felt so impassioned over an internet article or blog post that you wrote a scathing tirade, attacking everything about the person? Well, most people don’t have really strong opinions about it. 90% of people just read it and move on.

The angry critics reflect more on themselves then your actual writing. This blog post on online harrassment reached out to me on understanding the issues I run into with comments online.

For me, I know that the only people who are going to read this blog post are those that I share it with, and maybe a few bot scrapes.

Whatever Keeps you writing

The important thing to take away is to do whatever you need to get these projects complete.

Tips for Having a great Hackathon Experience

I recently participated in a few hackathons and hack nights this year. They are a great experience for developing a lot of interesting ideas in a short amount of times. It’s extremely rewarding to get a product out the door over a weekend, or even a night.

Some companies have made hackathons feel extremely exploitative. They’ll stuff a bunch of developers in a room, with free pizza and some prizes and they get to keep the results of your work.

The next time you see an interesting event to participate in, please consider these in mind.

Find a hackathon that put you first

Choose the ones that support your rights. We work hard for our projects, and they belong to us. A lot of issues arise due to some of these problems

Talk with your Local meetups and user groups for recommendations

Each of the ones I chose to participate had the following criteria:

  • The participant keeps all rights to the code they produce
  • The event has been vetted out by credible people with a good track record of support.

Finding a credible event can be difficult. Talk with your Local meetups and user groups for recommendations. In Orlando, we have a few tech advocates that go out of their way to check on these.

Once you find a decent hackathon that would benefit you, it’s time to prepare yourself!

Have a goal in mind

Having achievable expectations allows us to feel successful at these events.

Fellow hackathon team member Mick Musak recommended to set my expectations at the start the Hack the Arena event.

I chose a goal of just completing an app, and learned a bit more about how Web Sockets worked in Node.js.

I brought my friend Timothy Findling, who is very strong at a data-oriented project. He had very limited experience with modern Javascript and web apps. His goal was to receive free swag.

Keeps your mind grounded

At the Hack the Arena event, there were multiple groups that had similar ideas. Our idea of a digital light scheme was done on a hardware level, and I felt eclipsed. I messed up on the presentation, and felt really embarrassed.

Seeing that I was upset, Team members, Mick and Tim, told me their goals were fulfilled. They were proud to participate, and was happy to have the project on their githubs.

By setting the expectation, they were satisfied.

Here’s a compilation list of my goals at the past hackathons

  • Learn React
  • Learn React Native
  • Build a small fun game that I would play
  • Create an Android App
  • Don’t freak out when presenting the idea
  • Get a T-Shirt

Use your B-tier ideas

If you have concerns about being exploited for your brilliance and hard work, I have a great idea, well, a mediocre idea.

Save the best ideas for yourself, and use one of the throwaway ideas.

You’re a person who can come up with a bunch of ideas, and they’re cheap to think up. It’s the implementation that takes effort.

Leave enough for the imagination

Some may disagree with this idea, and that’s okay.

Use the Throwaway Jokes

I use my time at Hackathons to learn new things, or build a slightly interesting idea. This reduces the amount of personal risk to my ego when my awesome idea gets shot down due to poor execution.

This is where I pull out a list of joke ideas. In fact, a few local winners of hackathons have won with an X for Y product clone. These ideas are great for learning new tech.

Build for your audience

It’s really easy to try to do everything in a project for the hackathon. When we plan on a regular project, we try to get all the different features needed for the idea to work. On a time constraint, a lot of features are unnecessary.

Presentation Oriented Design

Many of the projects available relies on having the 3-5 minutes to present your project. Spend a fair amount of time designing what the screens would look like, and the basic flow of the idea.

This allows us to skip certain ‘crucial’ elements of an application, like authentication, or server communications.

Time is the ultimate enemy

Plan on creating the smallest MVP you can imagine, then make it smaller. Depending on the time of the hackathon, a lot of items are unnecessary.

Reduce the scope just enough to get your point across

OAuth2 Social Media Authentication for an instagram clone, don’t need it.

An entire backend server to process data, you might not need it.

On projects where I’m learning something completely fresh, or a lot of members with little experience, I want something super small and simple.

You’ll want to reduce the scope just enough to get your point across.

Keep your heart light

Tensions get high for competitors, trying to push out an idea as soon as possible. Remember to laugh, and believe that people are doing their best.

Environmental Variables for AngularJS

When it came time to setup deploys for our AngularJS application, we had a few areas in our Services that had hard-coded API keys into the application. A lot of guides online have different ways of incorporating ng-constant into the build process. At Fresh Lines, I work on a lot of server-side projects. I’m comfortable with a standard convention for my configurations, like a /config folder to store environment based settings.

This particular setup is based on onefootball’s guide, and mirrors closely to how some server side frameworks have handled their environmental variables.

Intended Usage

I want to have a nice config file, that lists all my environment specific settings, like

{
"business": {
"url": "http://tommylee.co"
}
}

and in config.production.json.

    {
"business": {
"url": "http://frshlns.com"
}
}

then have the ability to inject the configuration into places where I need it.

var app = angular.module('brandtinker.businessFactory',['config']);

function BusinessFactory($http, $q, ENV) {
var url = ENV.business.url;
...
}

Requirements

  • An AngularJS Application
  • A (Gruntfile)gruntjs that works

Folder Structure

The project folders would be set up so that we have a separate config folder to hold all of the private information:

/app
/config
/Gruntfile.js

In this config folder, we’ll have the following files. These files represent the different environments we want.

./config.json
./config.production.json
./config.development.json
./config.staging.json

Installation Steps

Install grunt-ng-constant and lodash to your local project directory

    npm install grunt-ng-constant lodash --save-dev

(optional) If you’re using grunt-jit: Add grunt-ng-constants to your grunt-jit.

require('jit-grunt')(grunt, {
useminPrepare: 'grunt-usemin',
ngtemplates: 'grunt-angular-templates',
cdnify: 'grunt-google-cdn',
ngconstant: 'grunt-ng-constant'
});

We need to Add the Configuration JSON files to the Gruntfile. Add these lines to your Gruntfile.js. This should be at or near the top of the file. If you’re Gruntfile is not at the root of your project, adjust conf1 and conf2 to match. lodash is included to merge both JSON files together

var _ = require('lodash');

// Load the config file matching the 'profile' parameter, returns the default config + values from that file.
var buildConfig = function (profile) {
var conf1 = './config/config.json';
var conf2 = './config/config.' + profile + '.json';
if (!grunt.file.exists(conf2)) {
grunt.fail.warn('File ' + conf2 + ' doesn\'t exist.');
}

return _.merge(
grunt.file.readJSON(conf1),
grunt.file.readJSON(conf2)
);
};

Add the following grunt task inside your grunt.initConfig. This sets up the configurations to read the buildConfig and set it to an ENV file.

Replace the dest: path with you keep your scripts in your project. I only have a production and development environment.

ngconstant: {
  // Options for all targets
  options: {
    space: '  ',
    wrap: '"use strict";\n\n {%= __ngModule %}',
    name: 'config',
  },
  // Environment targets
  development: {
    options: {
      dest: 'app/scripts/config.js'
    },
    constants: {
      ENV: buildConfig('development')
    }
  },
  production: {
    options: {
      dest: 'app/scripts/config.js'
    },
    constants: {
      ENV: buildConfig('production')
    }
  }
},

Finally, in the build and serve tasks of Grunt, we’ll need to call ngconstant to our setup. grunt build is for production, and grunt serve for development. I would add this task as the first or second task to be run

grunt.registerTask('build', [
'clean:dist',
'ngconstant:production',
'wiredep',
'useminPrepare',
...

And for grunt serve

grunt.registerTask('serve', 'Compile then start a connect web server', function (target) {
if (target === 'dist') {
return grunt.task.run(['build', 'connect:dist:keepalive']);
}

grunt.task.run([
'clean:server',
'ngconstant:development',
'wiredep',
...

Then for every module where you would use this, include config as a dependency, and inject ENV

var app = angular.module('brandtinker.businessFactory',['config']);

function BusinessFactory($http, $q, ENV) {
var url = ENV.business.url;

Credits goes to onefootball for this setup.

Programming without Internet?

So I’m sitting in a trampoline recreation center for my sister’s party. Chaperoning and Chaffeuring around. With some downtime, and not in the physical fitness to jump around, it felt like a good time to pull out the laptop to work on some side projects.

At a few of these places, they offer guest networks as a common courtesy. Unfortunately, some of the free WI-FI connections aren’t that great, and I could not get a solid connection. What’s a guy to do?

In periods of network downtime, here are a few things I have done to feel slightly more productive.

Program by Guessing.

How many times have you tried this? Picking up a new programming language, or framework, we let the IDE and it’s QuickStart be our guide. Whenever I come from a language that’s similar, I do a little divination, programming by guessing at what the method names or standard library names are. Sometimes we can get lucky.This time was not one of those times.

Dissecting Examples

I’m pretty new to Android Development. For the short time I was without internet, I was thinking of doing something simple. I opened up a few template projects, and played with wiring up the different templates together. Android Studios’ UI Builder was a definite good use of my time.

I’m sure a lot of you have done this before. I opened up an Android Project through Android Studio, and started relying on AutoCompletes. I did rely on hitting Firebase for my application, and without access to the network, I started a little service of my own. I’m pretty comfortable with Rails, so I created a small API Service and routed the firebase urls to my localhost.

Write Tests

There’s probably not enough test coverage when we’re building our personal projects. Some form of test coverage would be great to do.

Future-Proof solution. Download it now!

While doing a little research, I came across devdocs.

One Man Development Team

I recently picked up a small project over the weekend. With the promise to myself to launch an MVP by week’s end, I needed to have a solid system down that worked well enough.

It is a customer rewards tracking system, so that a business can keep track of customer purchases, and offer discounts at time of purchase. This is meant to replace their current Access database.

Organizing Thoughts

Tickets and feature management is a must. I’ve tried other ticketing systems, and I wanted a little more integration with Github or Bitbucket. From a recommendation from my coworker Brandon, waffle.io has been a very good choice. Tickets integrated well with Github issues, features, and pull requests. Progress of the ticket was tracked as I pushed changes to feature branches.

Some required features to emulate the current system:

  • Cashier Login
  • Cashier can add a new customer into system
  • Cashier can add a visit and add a new reward
  • A report to determine when customers at the month are

Some new features requested:

  • Rewards to show up at intervals of dollars spent
  • Rewards for frequency of visits
  • Alerting the cashier at time of entry about the available deal.

Make sure it works

Since this is a part time project, I need to make sure that it’s functional enough for people to use. While I’m doing some things from a TDD perspective, I didn’t want to spend too much time debugging launches.

After enough listens to the Ruby on Rails Podcasts, I checked out Codeship’s continous deployment service to keep my application recent and working. It’s a change in pace to how I’ve been doing my projects.

There were some growing pains setting up Capistrano to deploy on my own servers. I wrote up some steps and left it in my project’s readmes. Overall I’m pretty satisfied on how it works.

Keeping it small and tight.

I don’t want to mess around with small details, like User Authentication and Authorization. Using gems like CanCanCan and Devise speed up my creation process.

For the front-end sections, I’m looking to find a better way to build interfaces. Right now I’m just grabbing Javascript plugins for search boxes and autocompletes, and its working out okay for an MVP.