Posts Categorized “Programming”
-
Storing a Trained Neural Network- How I Beat Mongo's Limitations
###The Problem We wrote an app that needed a personalized neural network for different users. Training a neural network with user data takes a long time. A trained neural network is a function. Most databases won't store functions.
-
The KISS Principle, or How I Made an App in Half a Day
###Rabbit Holes One day you come up with a great idea for a little project. You figure you already have all the tools and knowledge you need to get it done in a few hours, settle in with some snacks, and get started.
-
Analyzing nth Fibonacci Solutions
Calculating the [Fibonacci sequence](https://en.wikipedia.org/wiki/Fibonacci_number) is one of the first programs many people learn to write once they're past `Hello World`. Of course, there are many ways of solving this problem; for example, it can be solved iteratively, or recursively. I was curious if my intuitive expectations about the performance of a few different methods were correct, so I wrote five different programs that all return the *nth* Fibonacci number and put them to the test.
-
Using SpeckJS to Simplify Unit Testing
[SpeckJS](https://speckjs.github.io/) is "an npm module that parses JavaScript comments and outputs unit-tests." It allows you to implement TDD into your projects quickly and efficiently from within you main js files.
-
Let Gulp Take the Tedium out of Tasks
If you've spent any time writing JavaScript in the last couple of years, you've likely at least heard of [Gulp.js](http://gulpjs.com/). Smashing Magazine has an [excellent introduction to Gulp](http://www.smashingmagazine.com/2014/06/building-with-gulp/) that I strongly recommend reading if you are new to this build tool.
-
Test Driven Development, Part 3
This is the third part in a short series on applying test driven development to a JavaScript program using [Mocha](www.mochajs.org), [Chai](www.chaijs.org), and [Sinon](www.sinonjs.org). [Part 1](http://haileyfoster.com/Test-Driven-Development/) and [Part 2](http://haileyfoster.com/TDD-2/) gave a general overview of TDD and a brief walk-through of how to set up a testing environment. Part 3 will give a step-by-step example of the TDD process. I strongly recommend following along with your own code if you have yet to implement TDD at on your own, so if you have not set up your environment using the process described in Part 2, I suggest doing so before reading this post.
-
A Beginner's Guide to Test Driven Development, Part 2
[Part 1](http://haileyfoster.com/Test-Driven-Development/) of this short series on test driven development gave a brief overview or what TDD is, explained why you would use it, and introduced a few tools with which you can implement it. Part 2 will provide you with a step-by-step guide for how to set up a basic TDD environment using [Mocha](http://mochajs.org/) and [Chai](http://chaijs.com/). We will actually implement this environment in [Part 3](http://haileyfoster.com/TDD-3), and finally, Part 4 will provide additional details about when, why, and how to use [Sinon](http://sinonjs.org/) to test more complex programs.
-
A Beginner's Guide to Test Driven Development, Part 1
Programming and teaching have a lot in common. In some ways, teaching students how to balance chemical equations is a lot like teaching a computer to do so: you have to have a clearly defined goal, create a basic plan, differentiate to account for differing strengths and weaknesses (*cough* Internet Explorer *cough*), determine if you were succesful, and modify your plans if you weren't.
-
Wrapping your Brain Around JavaScript's Bind Method
I think everyone can agree that fully understanding JavaScript's keyword `this` is...challenging. The object to which it refers changes depending upon the context in which it is called. Fortunately, you can use JavaScript's native `bind` method to take control of matters. The code below demonstrates both the *need* for the `bind` method and works up to explain how exactly it work.
-
Deciphering Javascript Instantiation Patterns
Sometimes it seems like Javascript has about a hundred different options for doing just about anything. While this flexibility can be powerful, it can also lead to confusion as it is sometimes unclear that several different constructs all essentially do the same thing. For example, Javascript has a variety of instantiation patterns, which can also be considered strategies for creating new classes:
-
The Importance of Clear Communication
A couple of weeks ago, I was working on two pieces of Javascript code that would apply a test to each item in array. The function `every` would return `true` if all items in the collection passed the test, while the function `some` would return true if one or more of the items passed the test. Writing `every` was fairly straightforward using Javascript's `reduce` function, but because I was trying to use my `every` function in the `some` function to practice functional programming, it took me a while longer to write `some`. Worse yet, because both functions deal with many boolean values, they are a bit difficult to discuss. The first time I tried to explain my final version of the `some` function to one of my students, it just ended up sounding like gibberish; it sounded something like, "...so if every value is not false, not every returns true, so some is true." Fortunately the students with whom I was talking is quite bright, so once I showed her how the function worked with an example.
-
On Tinkering, Day Dreaming, and Persevering
Over the last week or so, I've been moving at a fairly rapid pace through Hack Reactor's precourse material. What I'm finding though, is that I'm spending a far greater amount of time learning related technologies and terminology (seem my last post) than I am actually solving the problems and reading through the material. I found this quite frustrating at first, but I've come to realize that this indirect learning is becoming more an more valuable. For one thing, its allowing me to accelerate my learning via transfer and adaptation.
-
Debugging the Debugger
Late last week I finally got into some completely novel concepts for me in the precourse work. The remaining Git ideas were fairly basic, but did describe the workflow HR expects us to follow). Not much interesting there. However, I then moved on to the section on Automated Testing, about which I had only had a vague understanding of the general idea before.
-
Reviewing
Since getting the HR precourse work on Monday, I’m happy to say I’ve been able to work through the first section fairly quickly. It involved a basic review of HTML, CSS, and Javascript, and I had actually already read all of the provided resources. Because I want to make sure I REALLY know this stuff, I still worked back through it all, recording particularly important/tricky points with Evernote to review yet again before my start date in late June. I believe I now have a strong understanding of all of the concepts I reviewed, but of course I will need to do a lot more practice–especially with CSS positioning!–before I really feel competent.
-
HR Precourse Work Day 1
After weeks of anticipation, Hack Reactor has finally released the precourse work to my classmates and me. Before seeing the outline of the work, I was concerned that there would be many topics with which I have no familiarity. It looks like I’ve done a decent job prepping myself, however, as I have at least touched upon almost everything on the list.