mojo - kn

You are likely one of the many folks (myself included) who have recently learned to love Elixir. I initially started down the wrong road with Elixir, but I learned a valuable lesson as I corrected course. It takes some adjustment to view the world in terms of a functional language, with lightweight processes, running on the Erlang Virtual Machine. My realization was that thinking in terms of visual diagrams enables this important mental shift. So much so that if you’re writing Elixir without drawing diagrams, I’m pretty sure you’re doing it wrong.

Don't let failing APIs get you down. (Zing!) If your software depends on various services, service failures can compromise part of your application or bring your application down entirely.

Designing interactions and states is a hard job to get right the first time. What looks good in a static comp often needs adjustments when implemented. There is a tendency to overcompensate to express a change that is easily recognizable sans-interaction. Also, once you start using the app you might find that what you originally designed is just plain wrong.

So, you’ve built a React Native app on Android that is going to change everything. Soon the fateful day arrives when you must release it into the wild, like a chick leaving the nest.

Well, no, but it will change the way you think about data...

One of the fastest-changing areas in web development is front-end JavaScript frameworks. Once you've figured out which framework to use, there is the daunting task of identifying best practices. Here's why we picked React/Reflux, and how we made it work for us.

As an Engineering Mentor at MojoTech, my primary concern is the growth of our software engineers. I want folks to be thinking about how their career can grow and how MojoTech can grow with them. Helping our engineers navigate the demands of staying current, excelling at their job, and growing in a trajectory that they find rewarding is vital to their, mine, and MojoTech's success.

We were working with a client who was developing a brand new app. Like many startups, the client was interested in a lean approach at first and wanted to quickly create a proof of concept that would also entice early clients of their own. To develop quickly without sacrificing reliability, we chose to leverage Haml and Rails's ActionView to create a solid little app. The client was pleased. As they began user testing and sales meetings, the feature requests started coming in. After discussing these requests with the client we settled on the next stage of the app and what do you know, we needed JavaScript. Where to go next? So many options. We chose React and Redux as a promising combination.

As a longtime Ruby programmer who has just recently begun to focus more on Clojure, I find myself continually surprised by all the little treasures that Clojure offers. One of those treasures is Clojure's sophisticated support for destructuring - it's even better here than in EcmaScript 6! To explain the beauty of Clojure's support for destructuring function arguments, we need a good example.

You have an idea. You’ve thought it through, and you’ve decided that software is the best way to bring this idea to life. At this point, you have a some guesses about how to improve the lives of your potential customers. You set out and you start building some features. You talk to customers and get feedback throughout the build, but eventually, you arrive at this question: when do you put working software in the hands of customers for real-world use? Some founders fall into something akin to the next feature fallacy: thinking that one more feature will finally make their product ready for release. However, as a small, early stage product, you have speed, flexibility, focus, and team energy that bigger products don’t. The best way to maximize these advantages you have is to release early and often.