Health to the Web

Just read a good article on Angular App Structure .  I left a comment and as I wrote it I realized (duh) that a significant part of the problem is one of consistency: Organization by type is inconsistent with what the logical application architecture is.  Over time, that inconsistency leads to bad design decisions and all other kinds of mistakes large and small. When there is consistency through the app from features to architecture to physical code, it makes it easier for everyone, easier to think and reason about the app, make design decisions, add more code, share a common terminology, work together etc. And when I say "easier for everyone" I include the product team, qa, management, designers and developers. Thats not to say there can't be differences between logical architecture and its physical manifestation. Sometimes that is necessary. But I think its works best if the logical and physical are mostly in synch and material differences are exceptions.  Buil

Well, the Twixt team (of which i'm a member) heard the kind of news on Tuesday Nov 17 2015 that you really don't want to hear: "all Twixt positions eliminated immediately" Big surprise. Business Unit head, senior mgt, product, support, backend and frontend teams, over 20 people, all laid off. Including myself. Wow. Twixt was started almost 3 years ago as the first new Product AppNexus built in a number of years. Twixt was the brainchild of Andy Atherton, business lead and Vlad Gorelick eng lead. I started in August 2013 when there were 6 devs. Since then the team grew to over 20 people spread over San Francisco and Mountain View offices. Twixt was a startup within a startup (AppNexus). The twixt team was purposely located on the opposite coast from AppNexus in NYC to allow it full freedom to grow and innovate. Twixt went live over a year and a half ago. At the end of 2014 we exceeded our targets for customer spend. We were all excited and proud when over $100M in s

I almost forgot about this one. I participated in a video shoot as promo for working at AppNexus. Man, I'm so "deer in headlights".

This is a technology blog about technology I use. But now and again I read a business article which I think is so right I will reference it. This is such an article recently published on Ad Exchanger. Well worth a read. " I believe that in 2015, ad tech hit the second stage, the Peak of Inflated Expectations, and is now just beginning its inevitable journey through the Trough of Disillusionment. Does this mean that ad tech was overhyped? I would argue that, in some respects, the answer is yes." and... " Lastly, put a halt on the growth story. Every business seems to want to tell a growth story. And yes, of course, it’s good to know that your ad tech company is growing. But bear in mind that the vast majority of ad tech providers are private firms, so no one with any experience believes the growth rates you’re claiming. "

We're doing it! Upgrading angular 1.2.18 to 1.4.7 There are breaking changes to fix as well as some new features to use. Here's what I found as I upgraded. I downloaded the zip file from angular code and then moved the files needed into app. Here's what we've found: 1. Update all things karma:  1.1 update your karma.conf to use latest libraries  1.2 use latest angular-mocks.js files I forgot this and lots of unit tests broke (moment of panic) so save yourself and update all things karma first. 2. We use ui-date for dates and the version we had failed with latest angular. I updated to latest ui-date code but found it has a known issue with manual entry. I modified the library code to wrap in a try catch as suggested in the issue. I'd prefer not to do that and prefer to check if date is valid but such validity checking is complex. 3. we wrote a couple of directives to check before and after dates; they pushed through a change to force validators to run

I was debugging an exception in our app which is running the minifed build (uglifyjs). Thanks to Chrome, {} allows you to unscramble minified code, so at least its more readable to the human eye Our code was:                     if (seller.state === 'New') {                         model.readonly = true;                     } the minifier converted it to:                 "New" === seller.state && (model.readonly = !0) pretty neat eh! an interesting way to write an if statement. However before rushing to adopt that as a style think about how easy both are to understand. As developers we should try to write code that's easy for others to understand I could write a cool looking if statement as the minifier did...but that's not as understandable to a human as the original version. Usually, over time, all your team will be reading and changing your code. Write good clear, understandable code. Let the optimizer optimize it. p.s. we're

I attended the HTML5 Developer Conference Oct 19 & 20 2015. Below are some brief notes from the sessions I attended. Videos and slides should be up soon. Most exciting new technology: css grid layout, I want it now, sooo bad Coolest session: Prototyping the Internet of Things with Firebase (so inspired I ordered an Arduino board to hack with my son) Best phrase: "Web has changed from where you get things to where you do things" Its here now: ES6 (widespread adoption is imminent) ES6 for Everyone! Speaker: Jamund Ferguson, Paypal - a good presentation but I'm already a fan of E6 - destructuring is so cool, arrow functions great etc - http://html5devconf.com/speakers/jamund_ferguson.html#session Falcor: One Model Everywhere Speaker: Jafar Husain, Netflix - used by Netflix, very interesting idea, very suitable for NetFlix use case i.e. returning large amounts of data, taxomonies, for client to render as well as search thru the json - I'd