RestlessThinker

Archive for the ‘JavaScript’ Category

The impact React Native will have on cross functional teams

One of the most undervalued elements in high performing agile teams is cross functionality of skills. As Jeff Sutherland explains in his book Scrum: The Art of Doing Twice the Work in Half the Time, he references a U.S. Special Forces team who are cross trained in medical assistance, and weapons. This ensures the team has all the necessary skills to complete the mission, from start to finish. This concept really breaks down with mobile developers, especially with the gap in skill sets with native mobile developers.

Small engineering teams that have native developers in their composition usually allow native developers to have to a limited contributions to web front-end development, and even more limited back-end contributions. The same cannot be said for other “full-stack” developers contributing the other way.

Alternatively, they break off the native teams independently and only have them contribute by platform. Want to reach a new audience by developing an app on another platform? Create a new team. This is difficult and expensive to scale, not to mention you’re adding risk by allowing the separated teams to be bottlenecked by any particular task. This also limits knowledge exchange and collaboration between developers and does not create a culture or environment for teaching each other. This can also create a culture of individual code ownership which can lead to individuals defensive about their code and other individuals thinking areas of code is not their responsibility.

Learn Once, Write Anywhere

JavaScript is one of the most commonly used languages today and React Native can de-silo teams to be more cross-functional because it optimizes for a common syntax that can be used for multiple platforms.

Artsy has a really good write-up of their experience using React Native in a new project without having to create a new team. This is proof that React Native can have an impact on existing teams, rather than only choosing React Native upon a creation of a team.

The need for “native knowledge” is still needed to make exceptional apps but does not require an entire team of native developers. This is an advantage when building a team, where you don’t have the distraction of trying to hire “rockstar developers” for one platform when you should be looking to build a 10x team.

Last Mover Advantage

Appcelerator has had cross a platform development solution with JavaScript for native apps called Titanium. React Native has a few advantages:

  • ReactJS – Gaining popularity fast. Having a widely used web tool reduces friction in trying React Native. By being a web tool first, it can gain early adopters that are “Team Web” who are advocates of JS being the language of choice for developing native apps.
  • Developer Experience – Unlike Titanium, React Native doesn’t have the barrier of license fees and IDE’s.
  • The Facebook brand for developers – They’ve come a long way from “move fast and break things”. With each open source project or platform they’ve released, they’ve been showing more of their craft at work. (I’ve always marveled at the Facebook iOS team and some of the engineering challenges they’ve taken on and solved.)

Not For Everyone

It’s still a bit early. Breaking changes, out-dated stack overflow posts, hard to find best practices and solutions in Google searches and very few team case studies.

This shouldn’t stop teams from experimenting with React Native. If teams aren’t looking for ways to self improve, then they don’t fully understand Agile.

 

Front-end JavaScript Logging and Crash Reporting

One of the biggest things I miss about mobile development is remote crash reporting. It was absolutely essential. It was funny at the time because it seemed like such a revolutionary concept but then I realized that I should have been doing this for both languages on the server and in the browser. Now that I’m not doing as much mobile development I started looking for a similar exception aggregation system. I was pleased to find a language agnostic system called Sentry.

Great, so I found my crash reporting system but the next step was how I was going to implement it on a large scale.  I quickly turned to the patterns that the most logging frameworks use in Java and Python. Native JavaScript’s console.log() was great, but didn’t offer the flexibility I’d want for a large scale app. I wanted the ability to have different log levels and display logs in the browser console when I was debugging things, but at the same time I wanted to report a crash if I ever invoked logger.fatal().

I did some searching for JavaScript logging frameworks and I found a port of Java’s log4j, log4javascript. I found this to be pretty awesome but I was skeptical of using it right away as I didn’t want something bloated that had a full kitchen sink. It does offer a lot, but there were a lot of features I was looking for, specifically the ability to create different logging adapters that would allow me to log to Sentry. One thing you have to be careful is that if you log too many fatal errors you could overload your Sentry server so you’ll have to load test and scale accordingly. Sentry does have configuration options for Redis queues etc. to handle large volumes of logs.

In order for JavaScript to log to Sentry, I’d have to use one of their clients, Raven-JS. Once I got that working standalone, I wrote an adapter for log4javascript that would allow me to log all fatal() and error() logs to Sentry.

If you’d like to take it a step further, you can create a wrapper that instantiates the logger and configures it for you.

com.restlessThinker.Logger = {
    getLogger: function (name) {
        var loggerName = name || null;
        var logger = log4javascript.getLogger(loggerName);
        var consoleAppender = new log4javascript.BrowserConsoleAppender();
        var globalLoggingLayout = new log4javascript.PatternLayout('[%-5p] [%d{HH:mm:ss}] [%c] ::: %m%n');
 
        var subHostName = com.restlessThinker.Util.subHostName();
        consoleAppender.setThreshold((subHostName === 'prod') ? log4javascript.Level.ERROR : log4javascript.Level.DEBUG);
        consoleAppender.setLayout(globalLoggingLayout);
        logger.addAppender(consoleAppender);
        // this can be modified to fit dev/staging/prod
        if (subHostName !== 'prod') {
            var ravenAppender = new log4javascript.RavenAppender('somedevkey', 'mysentryurl.com/2');
            ravenAppender.setThreshold(log4javascript.Level.ERROR);
            logger.addAppender(ravenAppender);
        }
        return logger;
    }
};

You can generate multiple loggers in different classes/files.

var logger = com.restlessThinker.Logger.getLogger('newLogger');
logger.fatal('log this to sentry');

I hope this helps!

JavaScript Interfaces

In my personal quest for the “History of Javascript“, one of the first things I wanted to analyze was code maintainability. I tend to favor code maintainability and testability when making architectural decisions in any language. Naturally this lead me to wanting to see if there were any design patterns or anti-patterns in JavaScript. My first choice was  Pro JavaScript Design Patterns: The Essentials of Object-Oriented JavaScript Programming. I must admit when I was browsing through the book I was very skeptical of it when I saw a section on Interfaces in JavaScript. I know that it can be very risky trying to implement non-native functionality into one language from another. It’s even worse when you try to shoe-horn a pattern into a different language where it’s clearly not needed. I also strongly believe that languages evolve to help eliminate the need for developers to implement design patterns and that the languages themselves can have the patterns built in.

My favorite languages are both strongly typed and dynamic so it was a little hard for me to fully let go of types when jumping into JavaScript. When picking out this book, my main mission was “How can you create a large scale JavaScript application while still having it be very maintainable”? Any language can get unwieldly and design patterns aren’t a silver bullet, but I was curious to see enterprise methodologies applied on a free-spirited, hipster language. 😉

After reading it, it’s easy to see their perspective on when it’s necessary and that their implementation was very simple. We simply need to check if an object contains the specific methods defined in an interface. It uses duck typing to determine if the method exists, it doesn’t care about the parameters but just so you don’t get undefined is not a function. We obviously don’t want this everywhere but I find it works in a few scenarios. First, if we need to group classes. Second, if we must implement some design pattern that requires an interface. Third, if we have to invoke methods on a dependency injected object that we want to throw errors if a method does not exist and give other developers working on the same code feedback.

If you’re curious, buy the book or check out my example on GitHub.

 

JavaScript the Good Parts

Every front-end, full-stack, UI developer/engineer should have a copy of this book. Every dev team should have a copy of this book. Ironically the book is very thin, but it’s also great for a refresher every few months. It’s helped me enjoy JavaScript by simply avoiding the bad parts and pitfalls while telling me “why”.