I'm working on an exciting game called Our Story where players collaboratively create narrated stories with GIFs. The game runs in the browser and incorporated AI TTS (Text To Speech) for narrating the stories players create. To ship this game I needed to handle web development complexity and one of the largest hurdles I found was handling audio. The Problem Web Audio is a challenging problem because of the vast quantity of devices you need to support.
Building new things and enabling products to deliver better experiences to users is the things that makes development compelling for me. This surprisingly leads me to think about testing a lot. Testing enables changes to happen sustainably. With tests I have confidence that the existing product works as expected and guarantees that this doesn’t change as new values are added. The more time I need to manually validate, the less time I have to do the work I enjoy.
I've recently been learning React and Redux Sagas for a new project I'm joining. It's been fun transitioning from Angular and learning what project organization looks like without an opinionated framework. As I looked through the code I started to notice that yield is used a lot to generate values and pass those values to the Redux store using redux-saga. I haven't worked with yield yet so I needed to do some research.
I'm a software developer working at a company that regularly employs developers and technical leaders without a degree in computer science or engineering. Compared to previous jobs where everyone, including me, had a Computer Science degree, I find this is preferable. I collaborate with people having different perspectives, who possess a more varied array of skills from their backgrounds. Skills that come in handy when we need to think on our feet, solve a problem, do something most of us have never done before, or when we need to work through a client challenge.
Technical leaders have a challenging job. We look to these leaders to make decisions, mentor developers, lead meetings, and tackle the most difficult problems on our projects. These leaders are often considered the “best” developers and are placed in leadership positions because of consistent performance in the face of challenge. However, while technical leaders have many roles and responsibilities, they also have an arguably more important responsibility to enable those they lead.
This blog post was originally written for and posted on Rangle's blog. You can find a link to the original here. Learning is a unique experience. It requires relating what we've previously experienced to new concepts and patterns. Those experiences are remembered specifically and each person remembers a concept a little differently. I remember a picture of a ball falling with labelled symbols, others might remember the equation, and some may remember the sounds of the physics hall.
This blog post was originally written for and posted on Rangle's blog. You can find a link to the original here. Web applications have been evolving dramatically in recent years and many techniques have evolved to help our applications run faster, respond quickly, and load easily. With a wide array of modern development techniques it’s easy to overlook all of the options. Server-side Rendering web apps is one such option that has really impressive benefits when implemented in our applications.
I love working on the full stack of technologies involved with developing an application. It's satisfying to design and implement a feature on the backend and request the data from the frontend application to render out something awesome. It's very rewarding but it can be a long process to set everything up. It's often a boilerplate experience and I often find myself doing a lot more devops than development. This got me looking for alternative ways to setup servers and systems that could aleviate this need to iterate on systems rather than programs.
This blog post was originally written for and posted on Rangle's blog. You can find a link to the original here. Successful web development requires delivering strong communication between backend servers and frontend applications. The end client of an API needs to easily understand how to utilize the system to develop features and improve the application. REST (REpresentational State Transfer) has historically been used as the paradigm for this communication.
This blog post was originally written for and posted on Rangle's blog. You can find a link to the original here. My name is Ben Hofferber and I am one of the recent hires at Rangle. Over the course of the last couple months, I ditched or sold all of my things and moved to Toronto from Boise, Idaho. Visiting and consequently moving to Canada were my first and second times outside of the United States.
Serverless Architectures are probably the coolest technology I've seen in the last few years. I think that these architectures will make huge strides in scalability, efficiency, and performance of applications. If you haven't heard of serverless before, let's first start with a definition: My definition: Building, customizing, and deploying services to production without maintaining servers. Industry definition: There are two different meanings: BaaS (Backend as a Service) and FaaS (Functions as a Service).
I've recently been unfortunate enough to work on the impending migration away from AngularJS toward the new Angular. Eventually AngularJS will be officially deprecated by the Angular team once Angular 2+ overtakes its predecessor. When that happens, security vulnerabilities may keep AngularJS from being used in production apps. This means now is the time to get out! I've recently been learning Angular with TypeScript and just want to say I really hate every single build system I've seen thus far.
I've recently come across some pretty effective concepts surrounding the design of endpoints. My career has been focused on backend server code recently where I've needed to create, extend, and refactor endpoints. I'd now like to share what I've discovered along the way that has made my endpoint code more maintainable, testable, and performant. I'll be using a little bit of ES6 style NodeJS code with Express syntax to explain my points.
DynamoDB is a NoSQL Document Key-Value Database hosted by AWS. They offer to serve their database as a scalable cloud solution offloading the work of maintaining a database from developers. DynamoDB also features many integrations with other elements of the AWS stack like triggering Lambda functions and analyzing data in Elastic MapReduce. They support downloading and installing a local version of the database for development which allows developers to test without worrying about being charged.
SASS is a tool built with Ruby that allows you to write CSS more simply with variable support and with an arguably nicer syntax. SASS stands for ‘Syntactically Awesome cSS’. The bare minimum SASS setup is actually to run it on Ruby and you can find out how on their website. Requirements Node and NPM. I'm using NPM(3.10.3) and Node(6.4.0) Setup Install node-sass npm install -g node-sass Create a SASS file to compile to CSS $width: 460 $height: 250 body background-color: #37474F .
Learning React has always seemed daunting to me. I've downloaded several ‘quickstart’ projects in the past and quickly become overwhelmed. With the huge chain of dependencies I wasn't able to get a clear picture of how it all worked. So I dropped it. I still used Ramda and other functional programming libraries, but I just passed React by because it wasn't approachable. Then Redux‘s author, Dan Abramov made a post titled “You Might Not Need Redux” in September.
I've recently been spending some time trying to improve my development techniques and one area I've been focusing on improving on is my testing practices. It isn't obvious to new programmers as to why you might want to start testing your code. After all, if you can test out something that you've written that works shouldn't it always work? Code can usually be assumed to be deterministic right? While that's generally true with small programs, scripts, and school projects, it doesn't hold up when it comes to larger programs and software.
I've been switching a lot of my controllers into components thanks to the recent addition in Angular 1.5. The switch has been a great time to dust off some old code and really think about how my bindings are setup. I've switched to a lot of single binds in order to improve performance by reducing the number of watchers. However, when I went to throw everything into a repeater element, I started noticing some strangeness.