In my last update, I discussed using Socket.io for the implementation of persistent server connections in our music visualizer app. This week, we inch closer to our ultimate goal of rendering thirty frames per second with Three.js and sending them to the to the server for rendering to video. Great strides were made, but I also discovered performance issues that have serious implications for our rendering approach.
No Time to Dally
First off, let’s break down our time budget. We get 1000ms every second, and if we want to produce 30 frames per second, then we can only spend a maximum of 33.33ms on each frame. That’s not much, and depending on scene complexity and the client hardware, it could take that long just to render the frame.
For a while now, Ignite UI has been the choice for large enterprises to create beautiful and powerful modern web UIs on top of their enterprise data. We (Infragistics) are now making this product available to everyone. We want to open up the most powerful and easy-to-use UI framework for Modern Web Applications to everyone. In order to do this, we’ve made the majority of the line of business Ignite UI controls and components open source, and available on GitHub to everyone to grab! The open source part of Ignite UI is licensed under Apache 2.0.
As part of opening up Ignite UI, we’ve also created easy to grab NPM and Bower packages, and we’ve made the product fully AMD compliant. As any other open source project, Ignite UI is open to external contributions, provided that the contribution guidelines documented in our repository’s wiki page are being followed. The repository is still fully owned and maintained by the Ignite UI product team at Infragistics, so everyone is able to see how our own team contributes to the product. We’re also opening up our planning and tracking process, as all our plans are available on GitHub through issues and projects.
Ruby on Rails is a great framework for startups, but we often hear people talk about Rails scalability issues when a startup project grows too large (read: becomes very popular). One of the key events that triggered the discussion that rails can’t scale was when Twitter switched to Scala in order to handle their growing number of user requests. As a counterexample, we would like to mention that Shopify is an advanced Rails application that has scaled quite well many years in a row. So, who’s right? Do you need to ditch Rails if your app goes big?
Let’s take a look at how to scale a Ruby on Rails application to find out.
Have you tried ngFor in Angular 2? I bet you have. If you try the Angular 2 release candidate or later, you may have noticed a pervasive change that affects nearly every early adopter of Angular 2. The syntax changed very subtly.
The new syntax is super easy to refactor. However being inquisitive like we are, my friend Ward Bell and I wondered why it was made. This post helps explain why the late change happened based on our perceptions.
Most of this post came directly from my friend Ward’s thoughts. I suggested it was awesome and useful information and requested he let me post it. He agreed. And here we are 🙂
Overview of *ngFor and ref-
Here are the changes to the micro-syntax for ngFor.
We now use let item of items instead of #item of items inside *ngFor.
Outside of *ngFor, replace all var-x with ref-x
The terminology also subtly changed. What we used to call a local template variable is now either a template input variable (inside *ngFor) or a template reference variable (outside *ngFor).
Whether you’ve been building Angular 1 applications or you’re brand new to Angular, this workshop will provide a ground-up approach to learning Angular 2 concepts and by the end of the day you’ll understand how all of the “pieces” fit together.
The workshop explores the core concepts that will help you build end-to-end Angular 2 solutions including the role of ES6/TypeScript, project setup, code structure, style guide, using the Angular CLI, data binding and MV*, abstracted remote data calls through services, observables, and routing.
You’ll experience several demos and be provided with the code throughout the workshop, as you learn how to build apps using Angular 2.
We’ll explore and learn:
Why use Angular 2?
Getting started with the Angular CLI
Bootstrapping your application
The Role of Components
Using Decorators in Components (metadata)
Dependency injection and providers
Binding data to views
Input and output properties
Managing remote data calls using services
Http and RxJS Observables
Routing and page navigation
If you’re looking to get a jump start on Angular 2 and learn how you can build robust apps, then come join us for a day of learning and fun!
Bring your laptops, as we’ll include some “code along with us” activities.
Whenever Dan and I get together we have a great time. We hope you can join us!
Last week I had the privilege of coding an Angular 2 app in front of the live audience at the 3rd annual ngConf event. I had a lot of fun and, perhaps luckily, I didn’t make any major mistakes 🙂 More importantly, I believe this session shines a light on the seven most fundamental aspects that we need to build an Angular 2 app.
We all love tools that help use code more efficiently, so stick around for the end where I rapid fire some tools you will want to check out. Some of these include snippets, a CLI, and the official Angular 2 Style Guide.
The formal session description is shown below:
There’s been an awakening in the Web. Angular 2 has arrived and it’s time to learn the key features that help you successfully build Angular 2 apps. We’ll create an Angular 2 app from scratch, add components to track Star Wars characters, and configure routing between the views. The data may be needed throughout the app, so we’ll create a shared service and use dependency injection to access it from the components. We’ll also cover accessing data via HTTP, using metadata to describe components, and the new templating and data binding concepts in Angular 2. You may not walk out a Jedi, but the you will feel the power of the force.
What happens when a new version of node is released? What if you need version 0.10.36 for one app and 4.4.2 for another? Did you know version 6 is out now too? Yikes! it would be great if we could manage multiple versions of node on the same computer.
These are 2 different tools that allow us to host multiple versions of node. We can use it to select which version to activate, and the toggle back to another version in seconds. They are super helpful.
I prefer n, but it only works on a Mac. We can install it by running npm i -g n. Simply run n 4.4.2 and it will install that version. Watch this clip to see it in action.
Learn more about how to toggle between versions or install new versions of node from n‘s docs
If you run on Windows, nvm is very similar. In fact, nvm runs on Mac and Windows.
Either way you choose, these are vital tools for every node developer.
Why should we be using Angular 2? What’s all the chatter about? It can be difficult to keep up with the fast paced Web, so we all need tools to help us filter out the noise and focus on the things that add value. That was our intention behind this webcast on Angular 2 from Pluralsight.
We had such a large attendance that we all nearly broke the webcasting tool. Seriously. OK, so that never should have happened, but lesson learned.
Not to worry, though. We covered a lot of ground on why we should all be looking at Angular 2 and some extremely valuable tools like the Angular 2 style guide, code snippets, CLI, and codelyzer.
When it was time to start the Q&A session, I opened the question list from the attendees and there were over 1000 questions! Therefore I began a wickedly fast paced Q&A at the to cover as many of them as I could get to :).
There’s been an awakening in the Web. Angular 2 has arrived and now’s the time for you and your tech team get on board. Learning the key features to help you successfully build Angular 2 apps can dramatically transform the way your developers tackle large-scale projects. Knowing where to start, which projects you should begin with and how to get your tech team started on an epic journey.
Join Pluralsight author, John Papa, in this live webinar, where we’ll create an Angular 2 app from scratch and add components to track Star Wars characters.
The data may be needed throughout the app, so we’ll create a shared service and use dependency injection to access it from the components. We’ll also cover accessing data via HTTP, using metadata to describe components and the new templating and data binding concepts in Angular 2. You may not walk out a Jedi, but you will feel the power of the force.
Solving deep technical problems is fun. But by taking a step back and examining how we got here can be just as fun and useful.
We pride ourselves on our technical abilities. But an even more important skill we can have is not technical, it is a pragmatic skill: we can ask “why?”.
Why is such a simple word but it helps us evaluate how we got this our current point. What decisions did we make? What influenced us? Has any of the information changed since then? Did we miss a perspective or an option?
I find that this skill, when used with empathy, respect, and patience, proves its value repeatedly. The value is in uncovering new options or in reinforcing the direction we already traversed.
Have you heard one of these before? “This component is just so complex it requires all 2000 lines of code.” … or how about … “We can’t write unit tests for this code.”
Over the years I’ve heard these often. The interactions usually go something like this with a developer team. And sometimes I’m the one helping, and sometimes I am the one receiving the help 🙂
Me: Why don’t you have tests for this component?
Team: This component is just so complex that we can’t test it.
Me: Why is it so complex?
Team: The business rules have many variations and branches. Also, there are many rules we have to go get other data so we can make decisions.
Me: Why do the rules and data all have to be in this one component?
Team: Well, they don’t but the code is very intertwined. Perhaps we could pull out the data calls.
Me: Good idea. Why do all the branches exist?
Team: The branches help decide the course of action.
Me: Do those decisions have to be made in other places too?
Team: Yes, in some cases. We can break those out into services too.
Me: How do you keep up with the complex logic?
Team: We write tons of comments.
Me: Are the comments all correct?
Team: No, the accuracy is difficult to maintain.
Me: Have you tried moving that complex logic to a function named for what it does?
Team: No, but let’s try that now!
These types if interactions are trimmed down a bit, but usually they take anywhere from five to 20 minutes. Let me be clear … these are all with very intelligent and accomplished teams. And sometimes I have been the one on the receiving end of this (and grateful for the help). We don’t always see every angle. We sometimes make assumptions that cause us to miss things.
These types of retrospectives can help illuminate the options.
Open the Code and Refactor
Sometimes I open the code and start refactoring with them. One time in particular I recall a team pushing me out of the way about ten minutes into the conversation and refactoring the code themselves. This was the best result possible, IMO. This was a super bright team who just needed a gentle nudge in the right direction and then they were off and running.
I find that opening the code and doing it with a team via pair programming is a very productive way to help solve problems. The best part is when you hand over the keyboard and the net result is code that is:
has less or no comments
And my favorite part is that often there are less lines of code overall. It is pretty darn cool when we can accomplish all of this by refactoring our code to be better and have deleted more lines than we write!
Smaller Bites of Shareable Code
Moving code into smaller and more digestible functions make it easier to read, share and test our code. Take any large function and we usually find several conditionals, guard logic, calculations, formatting, and then some final action which returns a value. Try this exercise and break down the function. We may have already done this if we see lots of comments explaining the steps the function takes. (more on comments in a moment).
Now take those individual steps inside the function and replace them with smaller functions. Now our function goes from being a long function doing many things to a series of smaller functions, each doing one specific job. We’ve now reduced our the responsibilities of each function and made it easier to test, share, and read.
Replace Comments with Named Functions and Variables
We can take comments and replace them with a function. Why? Consider a comment on some logic that explains how to check for the customer’s credit. Why not replace that comment with a function named let credit = checkCustomerCredit(customer) ? Or better yet, let’s move that logic to a customer service and do this let credit = customer.checkCredit();. Now we move logic to a more testable and shareable state and we remove the need for comments.
OK, so making it shareable is an easy win, but I often run into remarks like “comments make my code more readable”. Sometimes they do when used for things that are reporting consequences for things that are not obvious or for TODO’s. But the vast majority of the time we can remove comments and replace with variables and functions that make sense and are readable.
This has the added advantage of making our code keep us honest. How? The comment is not a runnable line of code. It is easy for it to become incorrect. If we use a variable name or function name, it helps keep us honest.
Don’t be afraid to step back and re-look at the problem. Why are we here?
It is easy to hide in the weeds of the problem, but it’s an even better idea to step back and consider a few questions:
are we addressing the right problem?
is this going to help us achieve our story?
is the priority of this important?
have we considered all angles?
why did we toss aside these other options?
if someone else looked at my code, would it make sense to them?
It’s OK to re-think. It’s OK to make changes. It’s OK to ask for a second set of eyes. Of course we all have deadlines, so we don’t spend days on this … but we can do ourselves and our team an injustice if we focus on the trees for the forest, instead of the other way around.
Recently I had a great opportunity to sit down with my good friend and expert Angular developer Ward Bell to film a Play by Play for Pluralsight on Angular 2. You can watch Ward and I build an Angular 2 app from scratch, and see us explaining the decisions we make as the code unfolds.
Here is the description of the video with us …
In this video, Curious about getting started in Angular 2? This Play by Play will get you up and running in under two hours. In this course, Angular experts John Papa and Ward Bell build an Angular 2 app from scratch. You’ll learn about the various options for spinning up an Angular 2 app, including the Angular 2 QuickStart on Github. Once installed, you’ll see John and Ward add test coverage (and learn why Ward insists on end-to-end testing), work through building components, data binding, dependency injection, and handling HTTP requests. Along the way, you’ll learn best practices from two Angular masters, and valuable tips that will help you write better code and take advantage of powerful Angular features. By the end of this course, you’ll have a solid launching point for building Angular 2 applications of your own.