Equivalent Exchange

All About that FE FP - Diving into Elm

Sun, 06 Dec 2015 00:00:00 +0000

A few months ago, a relatively new programming language by the name of Elm caught my attention. In a nutshell, Elm is a client-side language that utilizes the functional programming paradigm and compiles down to JavaScript. If you visit its landing page, some of the described benefits of using Elm include:

No runtime exceptions
It's incredibly fast (as compared to popular JavaScript libraries, including React)
A clean syntax
Ability to incorporate existing JavaScript libraries in Elm apps
A Time-Travelling Debugger

While I've only had a chance to test a few of these claims for myself with the tutorial I just completed, I can say that I do like what I'm seeing so far. I wanted to write down a few immediate impressions, as well as notes for my own reference as I dive deeper into Elm.

To get a small sense as to how Elm works, here's a quick overview:

Elm structures its applications between Models, Views, and Updates
- Models and Views for the most part behave as you'd expect if you're familiar with other app architectures (ie MVC), and Updates determine what type of behavior will take place in response to user interaction

-- An example of a few Actions, followed by their respective Update behavior

type Action
  = NoOp
  | Sort
  | Delete Int
  | Mark Int

update : Action -> Model -> Model
update action model =
  case action of
    NoOp ->
      model

    Sort ->
      { model | entries = List.sortBy .points model.entries }

    Delete id ->
      let
        remainingEntries =
          List.filter (\e -> e.id /= id) model.entries
      in
        { model | entries = remainingEntries }

All data is immutable, so whenever things change, we pass around NEW instaces of the respective record(s)

-- This function updates a model's 'phraseInput' property
-- with whatever is passed along in 'contents',
-- and returns a new instance of that model (the original is unaffected)

UpdatePhraseInput contents ->
  { model | phraseInput = contents }

Elm's compiler is mindful of the TYPE of data you're passing around, so it's best practice to specify said types in each function's signature

-- This signature for the 'sum' function expects an Integer,
-- another Integer, and will return a new Integer

sum : Int -> Int -> Int
sum 3 4 -- returns 7

There are several ways to require and specify dependencies

import Html.Events exposing (..)
import String exposing (toUpper, repeat, trimRight)
import StartApp.Simple as StartApp

As with most functional programming languages, you can pipe data through multiple functions

-- This accepts a String message, an Integer for how many
-- times you want it repeated, and returns a String of
-- the resulting text uppercased with trailing whitespace trimmed.

repeatText : String -> Int -> String
repeatText message times =
  message ++ " "
    |> toUpper
    |> repeat times
    |> trimRight

Now that you have a sense of how Elm works, the demo app that I built following the Pragmatic Studio tutorial (which I definitely recommend) is a simple "Bingo" app where you can create new entries, sort them by points, and mark them once they've been "called".

The tutorial did a great job explaining the Elm fundamentals, and I look forward to diving into their follow-up course about Elm Signals, Mailboxes, & Ports. Some of the syntax still seems a bit weird to me (such as the numerous empty brackets when there are no attributes or children to add to elements), but I'll reserve judgement until I get more exposure and practice. That being said, I already do greatly appreciate the compiler's error messages, as well as the Elm REPL. These two tools made it super easy to begin learning and debugging, and are wonderfully done.

As mentioned, I'll do another post with thoughts, impressions, and misc. notes for the next Elm course. As of right now, my favorite tool to use for UI's is still React, but who knows, maybe that'll soon change! In any case, cheers to functional programming in the front-end!

Learn, Teach, Repeat - Joining the Offcourse Team

Sun, 29 Nov 2015 00:00:00 +0000

This past Summer I had the opportunity to meet and join the team behind Offcourse- an open source educational platform based out of Amsterdam. Though still early in development, when released, Offcourse will provide an environment for individuals to craft their own curriculum on any subject and share it freely with the world. Whether it's learning a new programming language, or learning how to bake a cake, community members ranging from beginners to industry experts will have a centralized space in Offcourse for creating and exploring these customized learning paths.

Offcourse is comprised of a small core team, who's currently collaborating internationally. These passionate life-long learners are working diligently around the clock (and the globe) to help make learning, sharing, and teaching as accessible as possible. Like the early stages of many startups, Offcourse is currently researching various fronts and applying new insights learned along the way. As the year's end draws near, a few of the team's goals include:

completing a beautiful, fast, and mobile-friendly UI
refactoring parts of the codebase to utilize new tech (namely Clojurescript)
regular blog posts about covering Offcourse's progress

You can find an early glimpse of the prototype UI here. In future releases, you'll be able to peruse the different courses and click on the tags for things you may want to learn later. If you have any thoughts, opinions, or questions about the platform, the team would love to hear it! Feedback has been vital in steering the direction of Offcourse, and it's mission to help shape the future of education. We've been fortunate to consistently receive feedback from college students, software engineers, academics, and we'd love to hear what you have to say, as well!

Happy learning,

Offcourse

Day of the Devs '15

Sun, 08 Nov 2015 00:00:00 +0000

Yesterday I attended Day of the Devs- an awesome annual event (with this being the third) where indie video game developers are able to showcase projects that they’ve been working on, including some that are just about ready for release. This is particularly exciting because, despite being indie titles with considerably lower budgets than larger studios, some of them have gained a ton of traction in the industry, so being able to play them before their official release was a great time.

Something that I really appreciate about a lot of indie titles is that more often than not, the team wants to create something unique and personal, as opposed to churning out a new iteration of some franchise annually like a lot of companies currently bank on. The games at DotD’s were bursting with character, beautiful art, and definitely made an impression. It’s really cool of companies like Humble Bundle, Unreal, Twitch, and Facebook to sponsor these kinds of events and provide a venue for smaller companies to bring their projects to the community.

I got some footage of the event which you can check out below. I had a blast and would encourage anyone who’s remotely interested in video games, programming, technology, or just the creative space in general to check it out next year! The best part of these kinds of events is chatting with the creators who are usually super excited to talk more about their work and answer any questions. There’s a ton of passion, creativity, and energy put into all of these, which is super inspiring and makes me want to get back to coding my own fun projects :)

Awesome stuff from Day of the Devs! Anyone down for some co-op? :)
Posted by Gregory Allan on Saturday, November 7, 2015

Weekend Mentoring at NodeSchool

Sun, 25 Oct 2015 00:00:00 +0000

Immersing myself in the tech community (and community in general) has hands-down been one of my favorite things to do since moving to San Francisco in 2013. When I first thought I might be interested in learning to program a few years ago, I remember how desperate I was to find someone - anyone - who I could go to with my questions. Beyond that, it would have been amazing to find someone who made their way into the industry through “non-traditional” means (self-taught, attended an “immersive” aka “coding bootcamp”, etc) just so I knew that the path I wanted to embark on wasn’t restricted to another 4-year program. For these reasons (and many more), I try to take any opportunity I can to participate in coding workshops and similar events that are free to all those who are interested. At its core, these events allow everyone to meet other members of the community, get help on whatever they’re coding, or simply get their questions answered- from absolute beginner to industry professional.

With that, NodeSchool is definitely one of my favorite organizations to participate in. Granted, I’ve only been twice (once as a student, another as a mentor), but both have been amazing experiences with truly awesome people who want to help an eager group of learners, however possible. The curriculum is free and available on their site, and offers digestible lessons that range from the very basics of JavaScript, to more elaborate and specific “electives”, including frameworks and libraries like React, Koa, and WebGL. The courses are for the most part ran in your Terminal, and are a great way to quickly dive into a new technology and get a feel for things.

As you can already tell, if you haven't checked out NodeSchool yet, I would highly encourage you to do so! Whether you’re looking to attend as a student or a mentor, it is a great time, and know that you’re contributing to a community who will want to pay it forward and keep the learning going!

HRX Startup Weekend

Tue, 06 Oct 2015 00:00:00 +0000

This past weekend I attended Startup Weekend, an event where engineers, designers, entrepreneurs and the like spend 48 hours together to not only create a prototype of a new product, but to also define a sound business model to support the idea. For many of us, the business side of things was brand new territory. As grads from Hack Reactor, we were expecting to spend our time this weekend coding away like a usual hackathon, but this event provided a different kind of challenge, and we were eager to get cracking.

The Pitch

Our group pitched and created AwesomeBox.Party. ABP allows users to have shared control over the music playlist at social events. By visiting the site and joining your event’s room, anyone can view the playlist, add to the song queue, and even bump up song priority using AwesomeBucks (in-app currency). ABP allows party goers and party throwers control over the musical atmosphere, so everyone can do their part to keep the party rockin.

Planning Stages

After we formed our team Friday night, we got started by white boarding our general plan for the weekend. We established what our MVP looked like, as well as stretch goals that we thought would be fun and challenged to work on before presenting the final product. We also discussed what kind of technologies would be best suited for our project, and much to my delight, the team was very excited about using React.js for the front-end. I was also excited to see that we’d be using Socket.io for the real-time communication between client/server, as I've yet to use sockets.

Hackers => Entrepreneurs?

As mentioned before, this event was a bit different from what most of our group expected. As the title implies, there is an obvious emphasis on the idea of building a startup, but even knowing that, we still couldn’t anticipate just how much business foresight we needed for ABP. We were told to build a business plan for monetization, determine the demographic, consider any legal issues, get real feedback from the public (if they would actually use our product, what should change, would they pay for X, etc). As an engineer, I definitely have more appreciation for the teams who take care of all these things- it’s tricky stuff!

Final Thoughts

Hands-down the best part of the weekend meeting and working with this awesome group. I can say with confidence that we all learned something new, and had a lot of fun in the process. Even when thrown into something completely new, everyone’s great attitudes and communication skills made the entire process much more streamlined and easier to move through each feature efficiently. I’d definitely be up for working with any of them again in the future! #TeamAwesomeBox

Comment Driven Development with SpeckJS

Thu, 24 Sep 2015 00:00:00 +0000

SpeckJS is an npm module that parses JavaScript and outputs unit tests. SpeckJS currently supports the Tape, Jasmine, and Mocha/Chai testing frameworks. Aside from it's standalone core module, SpeckJS also comes with plugins for Grunt, Gulp and Atom.

Our goal with SpeckJS is to make it as easy as possible to get started using Test Driven Development on a new project, to quickly add unit tests to your existing project, or anywhere in between. We know the value of well-tested code, and SpeckJS is here to make that simpler than ever.

To see just how easy it is to use, here's a GIF of the Atom plugin in action:

I'll be adding more posts soon offering an inside look at the development of SpeckJS, including technical hurdles our team encountered, interesting JavaScript discoveries we made, our Git and issue workflow, and more! But for now, you can visit http://speckjs.github.io to learn more! Happy testing!

Special Delivery! Creating an npm Package

Sat, 05 Sep 2015 00:00:00 +0000

Sharing is Caring

As developers, we rely heavily on libraries written by other members of the community on a daily basis. That's actually one of the best things (in my opinion) about being in this space- people are constantly pushing themselves to share knowledge, tools, and practices to help make others' workflows and daily lives that much easier. Some of these libraries come from huge companies like Google and Facebook, while other (just as popular) tools are contributed by small teams (or even individuals) who do this purely out of hobby. One of the best parts about this system is that creating and sharing your own package is made incredibly easy by npm, the node.js package management system. Who knows, maybe you'll author the next (insert 20XX hawt.js framework)!

Let's Get Started

This tutorial will assume you have basic skills with command-line and JavaScript

This example package that we're about to create is simply responsible for exporting a single function that console log's a message.

npm init

From the command-line, enter npm init. This will guide you through a series of questions including: who is the author, package name, package description, etc. Don't worry about having all of these answers right away- you can always edit the file that this prompt generates. When you are done answering the questions, it will generate a package.json file for you will all the information you just entered. You're pretty much halfway there to publishing your package!

package.json & index.js

In package.json, you will see a property named main, which represents the entry-point, or main file to load in order to start using your package. By default, it will assign the name index.js (which you can always change). Open index.js in your text editor, and we're going create a simple function to export, like so:

exports.myFunction = function() {
  console.log("Here's a message from your new module!");
};

npm login

From the command-line, run npm login which will either guide you through signing up for npm, or logging into your existing account.

npm publish

Once, you're logged-in, run npm publish from the same directory as your package.json file.

That's It!

If you visit the url "https://www.npmjs.com/~yourusername", you can view your new package, including statistics like download count, GitHub issues, etc. And now, most importantly, people can use your new package by running the command npm install _your_package_name_.

"How cool is that?!" (Rivers Cuomo voice)

Resources

Pick Your Parsing with Nick Balestra

Deep dive into deepEqual with Luke Savage

Stop Worrying and Love TDD with Zach Sebag

Holy Macro-roni!

Sat, 29 Aug 2015 00:00:00 +0000

Create Your Own JavaScript Operator using Macros

We want more

Recently, I've been learning more about how to get the most out of our favorite programming languages. Everyone knows that JavaScript in particular can quickly become unweidly and unsightly with just a bit of nesting, callbacks, etc, and many developers have already taken into their own hands to come up with solutions to produce more elegant, yet just as effective code from the natural (often referred to as "vanilla") language. One example of this is Coffeescript- a language that compiles into JavaScript, but is much more aesthetically pleasing to work with.

Enter, macros

As great as these other languages are, there's also another really nifty solution- creating macros. A macro is simply a piece of code that parses and transforms the code around it. Like most concepts in programming, this is a very basic idea, but also incredibly powerful when you consider just how it can help push a language forward. In this post, I will cover a basic example of how to utilize Sweet.js- a library for creating macros in JavaScript- to create your own JavaScript operator!

The awesome "Rocket operator"

The code snippets from this blog are taken from an excellent Sweet.js course on Plurlsight, which I'd highly recommend checking out if you like what you see here. What we're going to do is create a new operator to clean up the normal boilerplate code we'd expect to see in a regular JavaScript promise.

Here, we see a normal JavaScript promise (disregard the $ followed by numbers, that's known as "variable hygiene" which Zach does a great job explaining here). This is a basic example, but this syntax can get messy quick.

Now, we can use Sweet.js to create a macro to take the place of all that syntax, and still have it be incredibly expressive! Here's what's happening:

The '=>' represents a macro that does the same thing as a function "fat-arrow" from Coffeescript or ES2015 (aka ES6).
The '==>' represents our new macro that condenses promise boilerplate.
The '12' refers to our new operator's precedence (you can assign any value you wish). Every operator has their own precedence, which you can find here.
The { $l, $r } represents whatever will be found to the immediate left and to the right of our '==>' operator.
The => #{ $l.then($r) } represents our expected output. In this case, we'll have the code from the left of the operator, followed by a call to .then, passing the code from the right of the operator as an argument to .then.

And here is your new "Rocket" operator in action! Ain't it pretty?

Niceee. But why use macros instead of XYZ?

With some basic macro use, you have the power to extend your favorite programming language. Read about an awesome ES20XX feature/function that you wish were available today?? PutAMacroOnIt

Additional Resources

If you want to learn more about macros and Sweet.js, here are a few awesome blog posts to help you get started!

Case-based Macros with Nick Balestra

Rule-based Macros with Luke Savage

Macro Hygienity with Zach Sebag

Pluralsight Sweet.js Tutorial

Balance

Sat, 08 Aug 2015 00:00:00 +0000

Today marks the half-way point of my time as a Hack Reactor student. If there’s anything that I’ve learned over the past 6 weeks (aside from a boatload of JavaScript), it’s that maintaining balance during even the most arduous endeavors is incredibly important. I’ve been fortunate to be a part of a program that takes this into great consideration before we step foot through the (digital) door. They’ve allotted time specifically for exercise every other day of the ‘work’ week, which has been critical for keeping me in a state where I can spend hours at the desk (alternating between sitting and standing mode), and still be active enough in any given week where this intense studying isn’t detrimental to my health.

This is the general idea that I really need to adhere to during second half of the program. We will be afforded a ton of autonomy in how we move forward in the program, and with that, it’s up to me to maintain this schedule of regular activity and balance. I’ve used the metaphor a million times, but this type of learning is like a marathon, not a sprint, and with that I need to make sure I’m keeping my body in as good of shape to remain at an optimal level for the following 6 weeks, and beyond.

Obviously, this takes the mind into consideration as well. In order for me to stay mentally engaged and continue giving 100% to the program, what I do when I’m away from the keyboard is just as important as what I’m doing while I’m cracking away at JavaScript. Having this healthy balance will allow me to return to the work feeling reinvigorated, and often times inspired. It’s times like those that I produce my best work, so for anyone with similar behavior, it’s important to stay congnizant of this so you don’t hit a point of diminished returns. I greatly look forward to each challenge every day, but I also keep an eye out for things outside of the screen for inspiration to come back and go even harder.

‘Balance’ is a word thrown around quite a bit in these types of learning environments, and rightfully so. It may mean something different to each person you ask. but regardless of how you achieve it, make sure you’re investing that time into yourself. You’ll be surprised at the returns when it’s time to get back to the grind.

Measure Twice, Cut Once - Planning with Diagrams and Test-Driven Development

Wed, 22 Jul 2015 00:00:00 +0000

Last week I had the opportunity to work on my first Backbone.js project with another developer who was also trying the framework for the first time. We were building a Blackjack game, and going into this project I knew that Backbone takes a bit of a different approach to structuring applications compared to frameworks that I’m used to, specifically Rails. In my mind, I have an understanding about how Models, Views, and Controllers are separated and behave, but in the world of client-side frameworks, this understanding was in need of some re-wiring.

This post isn’t intended to detail the difference between Backbone’s architecture compared to framework ‘X’, rather, a few techniques that helped me get the most out of my time while solving a problem with a new set of tools. When I’m trying new frameworks or libraries, I catch myself often spinning my wheels with some things that weren’t necessarily essential for the problem at hand. It’s very easy to go down a rabbit hole when playing with new technologies, because it (usually) is fun to tear things down and see how they work, and we as developers/engineers/tinkerers have this natural curiosity. However, when you’re on a schedule, you need to stick to a plan and remain cognizant of how you’re investing your time.

The first practice that I’ve really come to appreciate is creating a diagram of your application. As much as I love digital copies of everything, I find myself retaining information much easier when I put a pen to paper and start sketching things out. This became incredibly useful when approaching Backbone because, by its own nature, it has very little care for strict rules over architecture, leaving it almost entirely up to you to decide. For seasoned developers, this can be very liberating if you feel shackled by the ‘convention over configuration’ mantra of frameworks, like Rails. Seeing how this was my first go at not just Backbone, but a JavaScript framework in general, creating a diagram helped me by making me consider the following:

the flow of communication and data throughout the application
how the event system operates
understanding the difference between DOM events (‘click’) and their relationship to user intent (‘Hit’ or ‘Stand’)
loose coupling between objects (minimal dependencies)

Below is one of the first diagrams that I created to get an idea of what the interface would look like, how they communicate, and what classes would be necessary for an MVP. I’ll likely be getting a whiteboard for future diagramming as we move into projects beyond the scope of toy problems.

The other practice that really made a difference in how we approached the problem is Test-Driven Development (TDD). ’Approached’ probably isn’t the right word, considering we didn’t start testing until we had the basic functionality of the game working (I know, not great), but it definitely made us reconsider a lot of the code we had already written. As we started writing tests, we noticed that we were simply writing tests that made our current implementation pass, rather than writing specs based on what we believed each component should do/be responsible for. As we began to place more emphasis on the latter, we noticed that a lot of our logic was placed in several illogical places, so we wrote specs for how the game should operate, and began refactoring to meet this new architecture. Upon finishing, we had much cleaner models/classes, functions with single-responsibility, and proper event handling. Prior to this refactoring, most of our code that we didn’t know where to place ended up in a central ‘dump’ that was globally accessible. Deleting this area after refactoring, and knowing that not only did our app still worked as well as it did before, but was also much easier to comprehend, was very satisfying. We thought that investing time to learn how to properly test our code would have taken too long, but it turns out we lost time needing to refactor everything we wrote, anyway. Had we started with tests and a clear plan from the beginning, we would have been much more productive from the start.

As I move into new projects, I look forward to the planning stages more and more. By adopting these techniques, I can gain a stronger understanding of how I want the application to work, what the architecture will look like (diagram), and the incremental steps in building everything out (TDD). By measuring out the scope of the problem and planning before writing a single line of code, I can greatly increase the chances of staying on schedule while maximizing my productivity. I’ll be sure to share more posts about these kinds of tips and tricks as I try them out for myself.