Skip to main content

Posts

#7 Programming, Scope and Contexts

One important thing to keep in mind while programming is scope, particularly when doing any sort of advanced programming. This is particularly important in JavaScript. The JavaScript Closure Loop issue , particularly that JavaScript is function and not block scoped. The difference between let and var in ES6 and how to avoid problems. Of course you could always use let as the Stack Overflow post suggests in ES6, but as of May, 2017 let is not supported by IE or Safari. So unless you've got a fancy transpilation process (there will be a post about this... how to setup a proper Grunt + Babel + Browserify scaffold with a sample starter kit), var will be around for some time to come. The issues around namespacing with JavaScript and why ES6 is such a huge improvement (or AMD or RequireJS). Specifically, why polluting the global namespace is horrible and why workarounds like (function () { // TODO }()) exist. How to avoid problems with var by using the var that = this idiom, and how
Recent posts

#6 - ES2015 / ES6, Grunt

Significant updates to my project over the past few days. Introduced grunt, modified all my JavaScript to use Babel + Grunt + ES6 style imports. All the JavaScript gets transcompiled to a dist/ directory, then the system gets executed through grunt. All works because all the paths are relative, and the correct files are copied over to the dist/ directory each time (also introduced a cleaning task). Basic stuff, but another pain that I wish I didn't have to deal with. The good thing is everything is setup on command line now, with rudimentary continuous integration (grunt watch) and a rudimentary build process. Introducing more and more utility classes, building out the foundation of the system... getting soon to the point where I can build out the system's widgets one-by-one, and hopefully my next post will be about rendering to the phone. Here's a portion of my Gruntfile.js in case anyone has trouble setting up their Babel + Grunt configuration... in particular, the key

#5 - Model Templating

Moving ahead with my work, solved a few problems, refactored my JavaScript libraries into something I can reuse I'm glad I don't have to use tricks like this to deal with JavaScript namespacing : Tons of ways people use to deal with the namespace issue like closures, IIFEs, etc., now that I don't have to do it (because I'm working on backend JS), JS becomes more bearable... So sharing this today, done awhile ago... what I do to generate my models is to use a template, (mustache.js in this case) then render the model... I have ~100 lines of spaghetti code that does it for now, actually parses an HTML template and inserts the properties into a model template.

#4 - Multi-File Configuration

Stopped counting the days, doesn't make sense with gaps. Trying to ramp up to many more hours a day.  Eventually I will be successful. Dealt with the "partial configuration" problem mentioned in the last post. Won't post that because it's very custom. I just used a recursive function to parse the JSON and if the key started with a # sign, replaced the value with other JSON. { 'key1': 'value1', 'key2': 'value2', '#subconfig' : 'path\to\subconfig' } => { 'key1': 'value1', 'key2': 'value2', 'subconfig' : [ ... ] } However, I will post a class I wrote to deal with JavaScript type issues. Some basic stuff. Hopefully, it is useful to someone. Uses the new ES2015 class syntax.

#3 - Data Driven Design

April 30th, 2017 - Day #7 Setup the basic process and rendered a view (not to a phone yet, but that will come). The next problem to deal with is the problem of partial views and subviews. All it does is takes some JSON, applies the properties and renders it to HTML. Simple process to a simple problem. Of course there's more to it than that. JSON -> PARSE -> HTML "The Process" It is apparently a trivial problem, but you can really shoot yourself in the foot with it. The reason why I say this is, I need a clear separation of design and logic. Even a 99% separation is not good enough, because I'm creating a 100% data driven application. Data driven is of course arguable, but the entire point is to mass produce some solution to a certain type of problem. Laying the Foundation So, basically I would like to achieve what's here  because I want a complete separation with the model and view. But not just because I like that or want that, but because I h

#2 - Working Prototype Diagram

April 27th, 2017 - Day #5 Didn't get a working prototype out. Didn't spend the time. That's not okay, but I will manage. Had other things to do, or not. Procrastination. But will work on it today. Need to drop it down to a repeatable pattern. Something that I can make over and over, that will make a little bit of money. Goal is to monetize as soon as possible. Make it simple and effective, just like the picture from a few days ago. Not worry too much about too many features. Next post will be a working prototype.

#1 - The Beginning

April 23rd, 2017 Two weeks after quitting to pursue my own hobbies and the "dream" of running my own business or making my own product, I find myself looking back at work career with fondness. So many things have happened over the past few years, people I've met and things I've done, that it's hard to make sense of it all. But in the end, it doesn't really matter. The only thing that matters is how fast I can make what I want, before my cash runs out. Time is of the essence. Starts with a simple sketch, anyone can make it... data driven business application. Better not to be pretentious and call it "engine" or "framework" because it's going to be the smallest, tiniest thing I can possibly make that works end-to-end that I can build on and expand on. How long have I thought of making this? Many months, many years. Always thought of work, responsibilities, all excuses... could have stayed to make it, but there was never the urgenc