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.
I want to have a nice config file, that lists all my environment specific settings, like
and in config.production.json.
then have the ability to inject the configuration into places where I need it.
The project folders would be set up so that we have a separate config folder to hold all of the private information:
In this config folder, we’ll have the following files. These files represent the different environments we want.
Install grunt-ng-constant and lodash to your local project directory
(optional) If you’re using grunt-jit: Add grunt-ng-constants to your grunt-jit.
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
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.
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
And for grunt serve
Then for every module where you would use this, include config as a dependency, and inject ENV
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.
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.
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.
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.
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 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.
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.
How do we find relevance in learning new programming stacks? How do we remain relevant in our understanding of web architecture? New frameworks rise and fall faster than a prime-time lineup. Wheels are reinvented faster than we can put them on cars!
When I’m doing things by myself or at my job, I want to get it done. I’ve developed habits to avoid using new / exciting / untested stuff for production. I also avoid rolling my own…anything. For the client, and for anyone else down the line, maintenance can be more expensive and mentally tasking. They want a working awesome product.
Coming up with new projects, I don’t imagine the minor (but important) details of my stack. I’m more interested in the end product. Architecting out a solution, drawing out my tables and relations, these are the parts I enjoy. My standard set of tools: Laravel / Rails, MySQL, Bootstrap, Nginx. Anything that gets it rolling out the door.
For me, it was the fear of failing to understand. After programming for a while, there was a certain comfort in knowing that things worked the way you expected them to work. Switching may take me a lot longer to learn, and cause me problems in getting what I want.
Life is hectic, and stressful. Programming is safe. It’s my sandbox.
Improving creative morale
I had a strange week filled with visits to the cinema. I thought of a game regarding movie earnings and Adam Sandler. Given a Movie title and the budget, provided by BoxOfficeMojo, the player had to guess the gross earnings.
Jackbox.tv’s online game model of an online sign-in and streaming looked amazing. I love the idea of a client-server game sessions, and the ease of sign-in. The interface is pretty slick. I want something like that.
Some of my other friends would take this idea, and form a medium-sized team where a lot of people do very little. Maybe make a Kickstarter from it. This is a silly prototype, and something that I want. So I started building.
It’s still not done yet. But the passion of creation is back.
When building is not enough
Meeting other people who appear passionate about the craft reminds me of why I started in the first place. I came to this industry since the challenge exists. While programming can be a solitary activity, we have a community full of supportive, brash, intelligent developers that can help.
Help a newbie
Working in coffee shops for the past few months, I met a few ‘up-and-coming’ developers. I’m not too sure what that means, but these kinds of people are extremely hungry and passionate about new stuff.
Encouraging their growth and development brings all the warm fuzzies into me. They show me their projects. I love seeing them. While I don’t have any pretty things to show yet, I have my favorite tools. I love showing off Github Pages and setting up their machines for Jekyll. Demonstrating the power of Virtual Machines and how easy it is for them to get a development environment setup so they can try out a new language or node.js tool. Or even helping them debug a current problem.
Contributing to Open Source
There are a few tools that I like to use, but documentation can be kind of scarce until I learned how to use it. Reading through open source code for fun may not be the first thing I went to, but helping to fix a bug that I ran into time and again helped.
Join a meetup
In college, I remember meeting with people of like minds, going through a similar trials and tribulations of finishing school work. I’m not used to meeting with other people with the same job title I have. Meeting up and Talking with others of like minds helps.
For our tests, we’ll use Pingdom’s speedtest tool. In Mid August, we ran some speed tests on the home page. Prior to August 10, some of the loading times was averaging in 5 seconds.
We looked at where the Time spent per each action, and a lot of time was devoted to server processing! This may be due to all the plugins.
In the waterfall, you can see that we have an image that takes ~3 seconds to load! Thanks Apache! This may be a strange server error.
There are a lot of things we tried to resolve this issue. We applied W3 Total Cache to the site to store some processing, some caching from CloudFlare, and we got slightly better numbers.
Unfortunately, a lot of those Caches only reduced part of the processing.
Switching to NGINX
From the Page Analysis Tab on Pingdom, we see that the majority of requests are static resources. Images, CSS and other things. This would be a good use case for Nginx.
We setup the site with Nginx and a Memcache, and on a separate instance. Even though we have 100s of requests on the front page, we got some pretty tasty results.
Hopefully we’ll get enough visitors to the site to actually need this.