A blog about visualizing, analyzing, and managing data
This document is intended to be a guided tour through some of my code. It will provide some insight into my skill set, coding style, and overall approach to developing apps. Scroll through this docuement to find the following examples:
Applications that are deployed to various physical and logical environments (AWS, Heroku, Dev, Prod, Local, Test, Debug, Language, TodayDate, etc…) will need a way to dynamically adapt to their current environment. The path to a file on AWS is definitely different than a path to a file on a disconnected development box.
Credentials for accessing outside resources (databases, s3 buckets, deployment services, etc…) should not be included in any source file (config or hardcoded in app) that will be checked-in to a source control system.
A smart module for handling config files is necessary. You can create your own, or just use one that has already been created and tested, like nodejs-config.npm install nodejs-config
Sometimes, using environment variables is the way to go. Like when the application needs credentials data such as username and password.
Source: [https://github.com/datadoodler/ts-00-active-webpack.git]
There are many options for using webpack. These notes won’t be an exhaustive treatise on the subject, but merely cover how to implement webpack for my usage current scenario, namely, the DataDoodler Administration Dashboard.
Basic webpack, and (optionally) the dev server, which provides a basic express app.
1 | npm-install --save-dev webpack, webpack-dev-server |
Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.
There are costs associated with how you write code (the patterns you utilize). Highly abstract code that relies on a high degree of inheritance, factories, and dependency injection is easier to change, but harder to understand.
Code that is less abstract is more likely to break something somewhere when you change it. Though it is harder to change, it is easier to understand.
How does code get from a developer’s machine through all the steps of testing and integration and deployment? A well-defined process flow is essential. Here are a couple examples of flows I designed and implemented.