Tuesday, December 10, 2013

How I Hide Important Credentials In My Rails Apps

I have been mentoring ruby on rails web development students for over a year now, and every quarter I end up explaining to them how I hide important passwords or credentials from showing up publicly on Github.  The most common way of hiding this information is through the use of environment variables.  Everybody seems to have their own unique way of handling this situation.  One popular option is to use the gem Figaro.  One advantage to using Figaro and Heroku together is that you can use their handy rake task to set all of the environment variables on your Heroku server.  Although using the gem is handy, I still prefer rolling my own solution.  Why use a gem when you can easily write your own solution and learn something along the way?

The first thing we need to do is create a file that will assign all of our environment variables locally.  We are going to create this in the config folder, and name it env_vars.rb.

NewApp/config/env_vars.rb

Since this file will contain confidential information that we do not want visible on Github, we will want to add it to our .gitignore file.  Do this by creating or opening up your .gitignore file, and add the following line to tell git to not track our file.

NewApp/.gitignore
/config/env_vars.rb

Now we will assign each of our environment vars inside the env_vars.rb file.  In my case, I will add a couple keys to access Stripe.  In ruby we assign environment variables as follows:

NewApp/config/env_vars.rb
ENV["STRIPE_SECRET_KEY"] = 'sk_test_Xxx0xxxXxXXxXxxXXXxxX0X0'
ENV["STRIPE_PUBLIC_KEY"] = 'pk_test_Xxx0xxxXxXXxXxxXXXxxX0X0'


Now we need to tell our Rails app to load these environment variables when the server is started locally in our development environment.  To do this we will modify our environment.rb file as follows:

# Load the rails application
require File.expand_path('../application', __FILE__)

#load env_vars file for development
env_vars = File.join(Rails.root, '/config/env_vars.rb')
load(env_vars) if File.exists?(env_vars)

# Initialize the rails application
NewApp::Application.initialize!

The lines that load and initialize your app are already included in your enviroment.rb file by default. It is important that you add our new lines of code after the rails app is loaded, but before the app initializes.  Lets break down what we are doing here.

env_vars = File.join(Rails.root, '/config/env_vars.rb')

In this line we are creating a variable named env_vars that equals the path that leads to the env_vars.rb file that we created.

load(env_vars) if File.exists?(env_vars)

In this line, we are going to load the env_vars.rb file if that file exists.  It is important to have this conditional statement so that the app will still load if the file is not present.

Everything is now set up to work locally, but how do we get this to work on Heroku?  Start by running the following command from terminal:

heroku config:set STRIPE_SECRET_KEY=sk_test_Xxx0xxxXxXXxXxxXXXxxX0X0 STRIPE_PUBLIC_KEY=pk_test_Xxx0xxxXxXXxXxxXXXxxX0X0


Notice that you can assign multiple variables at the same time by just adding a space in between them as I did above.

If you are not using Heroku for production, then you can just place an env_vars.rb file in the same location on the production server that has all of your credentials.

That's it.  We can run the same or different values for our environment variables in development and on Heroku.  Just don't forget to assign your ENV's on Heroku or you will be thrown an error when your app tries to access the unassigned environment variable.  Fell free to drop me a comment if you have any suggestion on how to improve this, or if you have a better solution.

Thursday, October 3, 2013

Addicted to Testing

I started learning to program using Ruby in April of 2012.  It is amazing how much I have learned in this year and a half.  I have built several novelty applications, an API for an iOS app, and a production application (Reading Glue).  Although I was able to build some decent applications, I have always questioned the reliability of my code.  If I tried hard enough, I seemed to always find holes.  Usually these types of errors were found by clicking around in the browser, and it took up a lot of my time.  There was an easy solution around this, and it was to learn testing.

People have told me about the importance of testing, but I have always had "more important things to learn."  I would tell myself that I did not have the time to learn, and really did not have the time to write extra code that was not essential.  Shipping a product quickly was more important in my eyes.  I recently started thinking about all of the time I spent clicking around in the browser to test out my code, and I realized that this time added up quickly.  I should have learned testing a year ago, and I needed to catch up quickly.

Starting yesterday, I have dedicated 5 hours each day to step away from what I am working on, and teach myself testing.  I have been using the book Everyday Rails Testing with RSpec along with Michael Hartl's Rails Tutorial, and I have a confession to make... I am addicted to testing.

So far I have learned some the basics of creating factories and writing RSpec tests for my models.  I look at my code much differently now.  As I write out different test specs, I start seeing holes in my current code.  Testing requires you to think about all the different ways you can make your code fail, and then find a solution to make the test pass.  In only 8 hours of practice, I have started changing the way I approach writing new methods.  Testing requires you to think about the problem and solution in a completely different way.  It makes you think about all the different ways something could "fail."

I still have so much to learn.  I have not even scratched the surface with what I need to know in order to create a solid test suite for Reading Glue.  If you have been putting off testing like me, then I really recommend you take a few days and work through some tutorials.  Don't just copy and paste code.  Type it out for muscle memory.  Better yet, don't even use their code.  Take the examples they use in the tutorials and apply it to one of your existing code bases.  That is what I have been doing.  Trust me, you will not regret it.

Wednesday, June 26, 2013

Pedal to the Metal

Two weeks after launching Reading Glue we have been petal to the metal busy.  As of today we have more than 425 users that have created accounts.  I have been flooded with emails and messages each day from teachers that love what we are working on.  I attended the Chicago Digital Learning Symposium yesterday, and received a lot of really great feedback there as well.  It is really easy to sit back and pat yourself on the back after hearing all of this feedback, but I have to remember that most of this feedback is coming from people that are connected to the field of education.  This is not to say that we have not heard from parents who love the product.  I just wish I was hearing more feedback from parents then teachers right now.  I think we all knew that teachers would really dig the overall concept of Reading Glue.  We have always planned on teachers being our largest marketing tool.  The bigger risk is building a large enough market out of parents who actually care to take a hands on approach when it comes to their child's education.  I am still optimistic that I can get non-teacher users to openly talk about what they like and do not like about Reading Glue.  It is really critical that I find out in the next month or two what areas of the site offer the most value to them.  I want to load the system with content before school starts, and really want to hold off developing all that content until we have some solid feedback telling us what works and what does not.

Some other exciting news came this week.  We found out that Reading Glue was selected to be one of the showcasing startups at Tech Cocktail's next event in Chicago.  As part of being selected we are in an online poll that is being held to select Chicago's Hottest Showcasing Startup.  We really need all the votes we can get.  The winner not only gets some extra time to pitch their company on the 25th, but they will also receive an invite to Tech Cocktail Celebrate ( a nationwide startup competition held in October).  All you have to do is check out this link, and scroll down to the bottom where you will see a blue button that says Reading Glue.  Click on us.  Feel free to vote for us from all of your electronic devices.  Even vote for us on your grandma's computer as well.  It would also be awesome to see as many of you as possible stop out to support us on July 25th.  By using this link you can get 20% off your ticket.

This week started off busy, and is ending that way too.  I am finishing up an application for the Impact Engine.  Impact Engine is a 16 week accelerator program that is focused on helping social and environmental for-profit startups.  They provide $25,000 up front investment for 7% equity in your company.  Cash is great and all, but what I think is most attractive about joining their program is the leadership and mentor network that you are connected with.  When you are a first time entrepreneur, like myself, you need all the experienced help you can get.  I think this is especially true when you are tackling a unique customer segment like Reading Glue's.

It is time to stop typing this blog, and time to get back to work on that application.  I have to keep the pedal to the metal and stay focused.  In only two weeks this ride has started to get a little wild.  I expect it to get bat shit crazy real soon.

Wednesday, June 12, 2013

Two Steps Forward

Two months ago I decided to quit my job and work on Reading Glue full time.  I reviewed everything that we learned in problem and solution interviews, and I realized that over the past few months I was building a solution that did not totally match what my customers had told me they needed.  Working on Reading Glue part time at nights had disconnected me from my customers.  I kept building onto a solution without any customer feedback.  The worst part was that I was modifying the solution in order to somehow come up with a revenue model.  I was no longer solving the problem people had expressed to me in the beginning, but making a pile of garbage that I dreamed might be able to make some money.  I scrapped all of my code base, and started building something new.  I started building a product that focused solely on one thing, solving my early adopter's problem in the simplest way possible.

Last night I officially launched Reading Glue.  We focus on improving a child's reading ability through the use of comprehension strategies.  At its core, Reading Glue is a resource for parents to find book and activity ideas that can be used to teach and practice the use of comprehension strategies with their child.  We help close the gap between the classroom and home by showing parents how they can teach and practice reading with their child just like a professional would in the classroom.

The response to Reading Glue has been awesome so far.  It is now time to learn from my users and see how we can deliver the most value while still staying focused on solving their biggest pain point.  We are making a big push by promoting Reading Glue through several summer reading programs.  We will also be applying for the Impact Engine, an accelerator in Chicago that is focused on helping startups addressing societal problems .  Lastly, I will be pitching Reading Glue at the Fox Valley Demo Day in Elgin on June 19.  I am excited to get out there and see where this can go.  There are bound to be a lot more ups and downs, but I feel like I am laser focused on what needs to be done now.  If you are a parent (or know a parent) of a child grades K-5, then we would love for you to try it out.

Reading Glue | Reading strategies that stick.
http://readingglue.com

Thursday, April 18, 2013

A Little Love for Reading Glue

As many of you know, I have stepped away from my full time job to focus on developing and launching Reading Glue. While working on the programming side of things, I am trying to get people connected to us either by visiting the site or by social media. It would be really awesome if you could help me out by spreading the word some. I have put together some small snippets you could use in an email, Facebook update or Tweet.

Here is an interesting site that is aimed at improving a young child's reading comprehension http://www.readingglue.com


Teaching parent's how to teach reading... what an interesting concept http://www.readingglue.com


This seems like a great way to reinforce what children are being taught in the classroom. http://www.readingglue.com

By no means do you have to use what I put together. I know many of you are much more creative then I am, so I am sure you could come up with some great ways to share the word. Feel free to promote our blog as well. It is at http://blog.readingglue.com on Tumblr. We are doing something a little different there. We are allowing the public to submit posts on our blog. If you know someone that might have some compelling experience to share with parent's, then please forward that link along to them.

I know it is a lot to ask, and possibly confusing for some of you who do not know what Tumblr or a Tweet is (Grandma I'm looking at you). Since I am unemployed, all I have to offer for your time is a big thank you and possibly a bear hug the next time I see you. I appreciate everyone's help!

Tuesday, April 2, 2013

Lessons Learned After Ten Years of Sales in the Manufacturing Industry

Last week I called it quits with my current career of working for Chi Cheng, a Taiwanese based electronics manufacturer.  I wanted to share some of my lessons learned from the past ten and a half years working in sales, engineering, and project management.

Everyone on the team has the responsibility of business development.

Every manufacturing organization has a dedicated sales/business development team.  This team may have the support of a sales engineer or project manager, but the responsibility of selling is pretty much placed on the shoulders of the account manager.  My belief is that everyone should be selling.  I have brought in more business as an engineer than I ever have by focusing strictly on business development or sales.  Whether you are a sales rep for a manufacturing company or just a floor sales associate at Best Buy, people immediately are on guard thinking you are trying to force a sale on them.  I experimented with this over the years, and 9 times out of 10 customers were more relaxed if I presented myself as an engineer rather than a business development manager.  They never felt that I as there to push a sale, but that I was there to help them solve a problem.  I could take the opportunity to present solutions that I knew favored my companies expertise.  Usually these were solutions that I knew our competitors struggled with.  Sometimes the solutions I suggested were not the most efficient way to manufacture something, but it was the only way we would end up being able to win the job.  The thing is that once you plant an idea in someone's head, it is hard for them to step back and think outside of that box for a better solution.  This is why I think it is important for every person in your company to understand they are actively be involved in the business development process.  Everyone needs to understand how their role can contribute to this process, and use those multiple roles to set you apart from your competitors during the whole sales process.

Being honest with your customer is the most important thing you can do.

I have built some amazing customer relationships over the years.  The secret sauce to these strong relationships is honesty and the trust that comes from being honest to your customers.  I learned early on that being completely transparent and honest with your customers is not a common thing in the ODM and OEM supplier industry.  Suppliers are always hiding information from their customers.  They only communicate information on a need to know basis, and they never communicated delays or mistakes until it was too late to recover.  Part of this has to do with the Asian culture not accepting and embracing failure.  By communicating your delays or struggles to your customers early on, you earn so much more trust with them.  My customers always knew that they could trust me to be transparent with the schedule impacts and struggles that come up during the development of a project.  You would be surprised how understanding a customer can be if you are up front with them about your struggles from the beginning.  Open communication allows for schedule or design changes to be made that might be able to help you.  Many customers feel the need to micro-manage suppliers.  When there is an open and honest communication channel, the customers are less likely to micro-manage everything you do.  Trust me, this benefit alone is worth it.

Use knowledge management as a way to make customers rely on your services.

I would say that knowledge management is probably one of the biggest issues that organizations big and small struggle with.  It is very easy to learn from your own mistakes, but the challenging part is to communicate these lessons learned to an entire organization.  Many times our customers struggled with this more than we did.  It is hard for them to manage this information across many development teams, and so it is up to the supplier to make sure that knowledge learned in the past is shared efficiently with the customer.  I have seen many projects where lessons learned were never openly shared with the customers, and everyone repeated the same struggles time and time again.  I think suppliers struggle with communicating this information, as it is easy to be perceived as a way of pushing back at the customer's design requests.  In some ways this is true, but it all comes down to how you communicate back to your customer.  Development engineers hear "we can't do this" from suppliers all the time.  Instead of telling the customer that something cannot be done, you can present a specific case backed by historical data.  Explain the cause, effect, and solutions based on past cases or experiments.  This allows a customer to make changes or suggestions based on actual experience rather than theoretical results.  Customers start to depend on you to help manage this knowledge learned over time, and breaking the relationship with you becomes harder.  Effectively using the lessons learned over time is an easy way to continue growing business with your existing customers.

These are the three biggest lessons that have helped me build a successful career over the past ten years.  Hopefully I was able to give you some ideas on how to improve your relationships with your customers regardless of the industry that you are in.

Friday, March 22, 2013

Last Day With Chi Cheng

Today is my last day working with Chi Cheng.  I am going to take some time to put together my thoughts on the past 10 years, and what I have learned along the way.  In the meantime I wanted to share an email that I sent to my team today.

As many of you know, today is my last day working for Chi Cheng.  After 10 ½ years, I have decided that it is time to move on to pursue other interests that I have.  It is tough to type this email as I consider so many of you as my friend.

I want to thank the management team for all of their guidance, patience, and leadership.  I only had a technical background when I came to Chi Cheng, but with the help of the management team I was able to learn how to effectively manage projects, engage with the customers, and how to lead a team to success.  Thank you for giving me the opportunity to learn and grow over the years.  I would not be in the position to achieve my dreams if it was not for the great mentoring I received from all of you.

I want to thank the R&D and PM teams for all of the excellent support you have given over this time.  One thing that sets Chi Cheng apart from all of our competitors is the innovative solutions we are able to come up with to solve problems.  You all have taught me so much technically, and I am amazed every day at some of the technologies we have developed over the past 10 years.  The PM team has worked endless hours in order to keep up with my demanding style of project management, and I cannot thank you enough.  ACC would have never achieved the great successes we have seen if not for all of your hard work.  In particular I need to say a special thank you to David Tan and his team.  I have spent more time working with him and his team then I have spent with my own family.  No matter the arguments or frustrations, his team always treated me with kindness when I visit ZCC.  Thank you so much.  As I step away, I have full confidence that you all are able to manage the projects better than I ever could.

Jeff, Judy, and Norman always made me feel at home during my 10 years at Chi Cheng.  I guess when you start out as a “family business” that mentality spreads around to all of the employees.  I always felt like family when I was working with all of you, and I think that is why it is hard to make this decision to leave.  Although it is hard to say goodbye, I am very excited for what my future holds.  I am taking a break from the manufacturing industry, and going to focus on how I can use my programming and business development skills to build products to make the society around me a better place.  I hope to continue relationships with all of you.  If any of you come to Chicago, please be sure to reach out to me, and I will do the same if I come back Taiwan or China.  Thank you again for everything.  I could not have asked for a better team to spend the past 10 years with.

Wednesday, February 6, 2013

What Would You Like to Do if Money Were No Object?


I saw this video earlier this morning and it hit home in so many different ways.  The video poses the question of what a person were to do with their lives if money were not an object.  How would that change the career we enter?  How would we focus our time and passion?  I have pondered this question on and off again for a couple years.  As a father of two young children, it is hard to discount the fact that having a stable and well paying job is important.  Making a change to just leave a job is a hard decision when you have a family who counts on you to provide for them.  I have recently made some decisions in my life which shall be revealed in later blog posts.  I was really taken by the quote "It is better to have a short life that is full of what you like doing, then a long life spent in a miserable way."  It may have taken me a long time to actually have the courage to act on this concept, but the past couple days have been such a relief knowing that the wheels are in motion.

Although I was inspired to make changes in my life prior to seeing this video, I thought it was important to share with anyone who may still be indecisive of taking a risk to make their life happier.  I hope you enjoy it as much as I did.

Saturday, January 5, 2013

Eating Some Rubeque

I took a little break from the major stresses of my life for about 2 weeks.  I completely disconnected from all things work related.  This included anything to do with my full time job or work on Reading Glue.  Wednesday I was back in the saddle and trying to catch up with the 500 or so emails that were waiting for me.  By Thursday night I was caught up and ready to get back into the groove of completing features needed to start user testing on Reading Glue.  I am not sure why, but I had to do a quick search for something related to a question I had with a Ruby class, and I came across the site Rubeque.  Rubeque is a site that has tons of Ruby koans (practice problems that you solve using code).  It is a great way to sharpen your skills using Ruby.  I had landed on the site a while back, but had not really played around with it.  I decided to try out a couple of the problems.  To my surprise, I was actually challenged a bit.  These were elementary level questions, and I felt that they probably should not be challenging me this much.  It really shined a light on how little I really know when it comes to writing code.  The past 6 months have been full of building Rails apps, front end coding, but I have not really worked on much Ruby that has forced me to learn more.

After being tested by a couple of the initial questions, I decided to put everything on hold that night and jump into working through some more problems.  My favorite part of Rubeque is the fact that after completing a problem, you are able to view other people's solutions.  I find it very interesting to scan through the different ways people attack and solve a given problem.  As I am searching for a solutions to my problems, I find myself reading through the Ruby documentation.  I always told myself that I needed to slowly work myself through the Ruby documents, but never took the time.  These problems have forced me to read through it to find the correct methods needed to solve a given problem. While playing around with these problems late at night, I have found this to be very addicting   Both Thursday and Friday nights I would tell myself that once I completed the current problem that it would be time to go to bed.  After completing the so called "final problem of the night" I would take a peek at what was next.  Being the gunslinger that I am, I would immediately try to quickly solve it.  Sometimes it was a quick solution, and other times I needed to study it a bit.  After completing that "final final problem of the night," I would take a peek again at the next problem.  The cycle kept going until I would get a text from Julie at 3AM telling me to get upstairs.

I am not sure where the name Rubeque came from.  Could it be any relation BBQ?  I love BBQ.  I love it probably more than any other food.  When I sit down to eat BBQ, I always end up overeating (as proof by my waistline).  I doubt the names have any connection, but I have found that I have a similar lack of portion control with Rubeque and BBQ.  It is a fun way to challenge yourself to learn better ways to code in Ruby.  I have completed the elementary level questions so far.  I would like to make it a goal to work on at least one problem a day.  So while others are making resolutions to trim off the weight for the new year, I am going to be gorging myself with Ruby.

Thursday, December 20, 2012

Social Coding, Why Did I Wait So Long?

I have been pretty active on Github for the past couple weeks.  Over the previous six months I have used Github to host my code so I could push to Heroku.  I also found myself on Github reading wikis or readme files for some of the gems I use.  As a beginner, I did not feel comfortable getting any more involved in the open source community.

A couple weeks ago I was watching my server logs and thought to myself "Wow, this favicon error that keeps popping up in my logs is really annoying."  It did not stop anything from running, but every call to a view in my app had an error that the favicon path could not be found.  I saw this error in a couple of my apps, and decided to find out what was causing it.  Come to find out the favicon path was being called in my application layout, which was generated by the twitter-bootstrap-rails gem.  It was a simple fix from what I could see.  I just needed to change favicon_link_tag 'images/favicon.ico' to favicon_link_tag 'favicon.ico'.  I changed my code in the application layout, and sure enough it worked.

When I was going through Code Academy (now The Starter League), we were encouraged to get our feet wet by helping out on some open source projects.  I always have been afraid to get involved.  To be honest I was not even sure how to get involved.  This seemed like a really easy fix to make, and I could get my feet wet by contributing to a project.  I went to Github, forked a copy of the project, and started digging through the files.  I realized the folder structure of this project was much different then I was used to with a Rails app.  There were generators, themes, and everything seemed different from what I was used to.  I was finally able to find the generator files that produce the application layout code, and revised the faulty favicon area.  I had to update erb, haml, and slim versions of the layout.  Now that I revised the code, what in the world was I supposed to do to get it back into the main project?

I searched Github and found their documentation to be very easy to follow.  All I needed to do was create a pull request.  As I created the pull request I started to get very nervous.  What if I did something wrong?  What if my code breaks the project?  I have errors in simple code all the time, so how was I to insure I did not overlook something in my little late night experiment?  I figured there was only one way to find out or learn my mistakes, and that is to submit the pull request.  Three hours later my pull request was merged into the project.

I know the change I made was really simple, but I was overjoyed that I was able to finally get my feet wet on a major project.  This also gave me some confidence to dive into the open issues and try to help out others.  Some questions were easily answered, and others were far more complex for me to handle.  One of the open issues was based off of the fact that the read me file was not clear about "fluid" meaning a responsive design.  I updated the readme file, created a new pull request, and this morning that change was merged as well.

Last week I also forked another gem to create a custom version of it for me.  The gem is called blogit.  I needed to customize some of the views and functionality for creating the Reading Glue blog.  I keep the modified version of the gem on my Github account, and can update my apps gem directly by the link back to my version on Github.  For the most part this gem resembles a normal rails app.  It was easier to know where to find files, and to understand what I am looking at.  It was also a great way to dive into more complicated code, and learn better ways to refactor my own code in the future.

One year ago I had no clue how to code outside of some very basic html and javascript.  Nine months ago I started looking at Ruby on Rails, and felt overwhelmed.  Fast forward to the present and I am feeling comfortable contributing to open source projects or forking other people's code for my own customizations.  I am not sure why I chose to wait so long to start using Github for social coding.  Maybe it was just a fear of getting involved and failing in front of the world.  I did not realize the learning benefits that come from contributing to the open source community.

Are you learning to code and only using Github as a way to store your code?  I highly recommend getting involved in a project.  Even if it is closing out open issues, updating a readme file, or something else that is simple.  You likely have the skill set to help out in some way, and I guarantee you will learn more as you continue to stay connected to the project.