asus zenbook

brent: i'm brent weaver and you're watchingugurus. the must-watch web series to become a more profitable and in-demand web professional.today, i'm in boulder, colorado hanging out at dojo4 with ara howard, their cto. welcometo the program. ara: glad to be here. brent: so ara, how did you get started inweb? ara: wow. so, i went into engineering school,computer science school after a really bad bike accident left me wanting something icould do if i was crippled. and so i went to school for a second time. i was livingin boulder and i went to the engineering school here, cs department which is a really greatprogram, had a really great time. was able

to partner with some really motivated students.and we were, things were looking great for us. it was right around the time like at thefirst dot com boom. and the crash happened about, oh i would say about three months beforegraduation. we had the friends who were juniors dropping out of school to go take the highpaying job. but i was living here and i had no reason to rush so i stayed. while i wasa student i ended up being a research associate at noah. working with weather modeling andbig geo-data. and i had thought that i was going to move on immediately to industry becausethe pay wasn't as good and i wanted a different challenge. so then the bottom fell out andthere were no jobs. the crash happened. right when we graduated a lot of my friends werereally scrambling for work. and so i was really

fortunate to be able to go into research.i say really fortunate because for the next five to seven years i was able to work withtechnology that you just don't get an opportunity to touch as a web professional. so i helpedport the weather model onto... and helped build what, at the time, was the fastest supercomputeron earth. the jet supercomputer. of course that only ever lasted about three weeks untilsomebody in japan supersedes it. but at the time it was amazing technology to work with.so we built massive 100 node compute clusters. and then while i was there i really startedto work into user facing code. there's a whole parallel world to the consumer web in governmentand the sciences. and everybody talks about api's and service layers. they were doingthat 20 years ago. and there's all these custom

protocols for moving data around the worldand interacting that scientists have been using for a very long time. and so i had atalent for that. and i was doing a lot of pearl, cgi programming, c, cgi programming.and one day out of like incredible frustration at installing lib dub dub dub[sp] from cpanand trying to get that to compile, i decided there was language i was reading about, ruby.it was about one, four. and i was like f[explicit]k it i'll try to do it in that language. andso i downloaded it, compiled it, http was built into the language. this was kind ofa new thing for a language to come with really good http tools out of the box at the time.and so in a matter of days i started doing all of my programming in ruby. it was a verysimple transition for me because i had done

lots of oo programming, lots of functionalprogramming, lots of scripting languages. so i just started doing everything in it.so stayed there for a few years. but still really wasn't touching the internet. and graduallystarted consulting for companies around here. mostly in the scientific domain. so startedworking for the very early start-ups in boulder. collective intellect and some others who hadfound me through use net. i don't know if anyone remembers what that is. brent: i still use it for various downloadingthings, but whatever. ara: and so i started consulting with whatwe would now called a start up. they weren't called that at the time. i don't even knowwhat these crazy companies were that were

funded by... who are these foundry guys? whatis venture capital? i didn't even know. but of course, they were doing... and i was initiallycontracted to do it like work in the heavy lifting in the back end. but of course theywere working on consumer facing products and so it was touching the internet. and thenrails[sp] happened. and i remember at the time a good friend of mine that i went toschool with, david clementine jumped on the rails bandwagon. rails won. another good friendof mine that i went to school with. and i remember telling them, he likes to tease meabout this, i was like why would you want to be a web programmer? that is so lame comparedto doing like real programming. it's like just kiddie stuff. but i was wrong. and itturns out that of course it's a fascinating

problem, it's super challenging. and i justended up doing it more and more because that's what people were doing. to this day dojo4still focuses on, our projects touch the internet, but they're not just the internet. for themost part. so we do ten to like work on projects that, sure there's an api. and there's a website,and there's a store. and it's http and people think it's a website, http only. ignoringthe fact that we may have built a custom video rendering farm with 2,000 ec2 nodes to powerthe whole thing. those are the kinds of projects that we still like to specialize in. so, someheavy back end stuff. brent: very cool. so in terms of you in yourspace. i mean you have to kind of be on the forefront of technology for what you guysare doing. like what kind of projects do you

take? what kind of projects do you not take?how do you keep tabs on all of the fast changing technology? and then making the decision ofwhat dojo4 works on, and what they don't? ara: well, even though i'm the cto, i meani'm a developer at the core. i write a lot of code. i still maintain over 200 open sourceprojects. i have hundreds of gems at this point in javascript libraries. i write a lotof code. it's what i do in my spare time other than ski or ride my bike. but if i'm sittingdown, i'm probably writing code. so i write a lot of code. i play with a lot of code.i build a lot of tools. i actually just sent an email out, or i posted a tweet last week...and i believe this, that you can estimate the quality of a developer by looking at thesize of their bin directory. and developers

that don't write tools for themselves, they'renot developers. like they just have a job and they happen to write programs. but they'renot developers. the creative... my first company and the company that's a partner in dojo4was called code for people. and that's what all my open source is released under. andthat name came out of that belief that i really want to write tools that people are using.i enjoy writing code, provided it's used. and so i do a lot of that. lots of spare timeprojects, lots of open source. so i guess in a way that helps you stay on top of technology.but when you're asking that question and i was thinking to myself you don't really haveto stay on technology. like on top of technology. nothing's changed. i actually find it quitehumorous that for us old timers that have

been around the web for a long time, likethere haven't been any changes. the fundamental paradigm... like http is still stateless.trying to keep connections open between servers and browsers to make things more responsiveand do things in javascript instead of on the server side. and then it flips and thenit goes the other way. i mean that's been happening since before firefox. i mean whenall of our development was on mozilla, i don't know if you remember was it cgi npn, right?you could leave a connection open with cgi scripts. people think this is modern. likeweb sockets, oh my god! this is a new thing! you're like it's 15 years old. or even theconcept of like meteor[sp]. it's like javascript on the server and the client, my god! it'slike inra[sp], the french research institute.

i forget the name of the framework, but theyhad that 15 years ago. even with a database layer that interpreted javascript. like onelanguage everywhere. so things just go like this. i was talking with some of the guysfrom pivotal labs yesterday. alex, a friend of mine. and he was saying he was doing alot of stuff in go lang. and we just rebuilt dojo4 recently and it's purely static. i'ma huge fan of static websites. and it's generated and we have robots that listen to web hooks.and so practically speaking, it is a dynamic website. we can write blog posts in a webbrowser and hit publish and it gets published. but in reality, it's a static website. andi was looking at it, the build is a little slow. i mean i would like the build to befaster. it takes about 200 seconds to build

the site. and that's fine for the benefit,which is an incredibly fast loading site. but i had wanted to make the build a littlequicker. and i was looking at a variety of statics i generated out there. i was lookingat doc pad and hugo which is one based on go lang. it was my first... everything ingo is awesome and it's fast. and everything in node is like it's fast. so i looked atthose and put some representative data together and i was like yeah they are fast. i couldget a build of say of 500 page site with reasonable complexity... i could get it down to the tensof seconds. that's hey that's an order of magnitude. and then i remember... and theni just had an idea... again, us old timers that know what wget--mirror[sp] is, so i wrotean alternate implementation in ruby again.

just on rails, nothing fancy. and spun upa passenger instance with 16 threads, spun up wget against it and pulled it down anddecided to see how fast that was, and it was about a second a half. so no new tooling,slow language and i'm going two orders of magnitude faster than what i was doing. andfaster than the compiled languages, which are fast. and that's a great example of hownothing changes. when i was at noah we used to do a lot of image processing with ruby.people were like ruby is slow. well, i mean it depends on how hard you think about theproblem. so i just find that the aspects... i mean the rules around programming and theweb. i mean they haven't changed. we still have touring[sp] machines. we still have contextre-grammers. we still have stateless protocols

between servers and clients. we still havejavascript in server side scripting languages. from my perspective there have been no changes.the only changes that i think that has... the only real change that i think that wehave seen in 20 years of web development is proliferation of devices. although there weresome of us, myself included, that thought that i've never written css with pixels inmy life. that's always seemed like a f[explicit]king crazy idea to me. right? like as a developeri'm like a pixel is a unit over there. and you have different sized screens. like whata weird idea to take this print idea and try to apply it to a screen. very strange. likewhat if i want to render it as a pdf? like i have always believed in a separation ofcontent and presentation. so i used to make

designers very angry. i would take their cssand i'm like no it's all m. it's all percentage based m's. everything else is crazy. and thiswas ten years ago, and now it turns out that there are a lot of screen resolutions. thepermutations of screen size, that's been a real change. although a relatively minor onefor some of us who have been thinking like that. thinking responsive from the get go,separating presentation from data. but the combination of the proliferation of screensizes with rendering engines, with technologies to deliver data to that, right? single pageapp, api, whatever. server side, http caching. and then one of the biggest things, i thinka variable connection in speeds and/or connectivity like on offline. you add all that together,and i do feel like the web right now is far

more complex and far more interesting thanit ever has been before from a development perspective. everything is hard, i feel likenow. and people's expectations are through the roof. they say web app... i remember onetime when we made a presentation for a big client who was selling a company to a biggercompany that starts with o and ends with -acle. and we were making the presentation in 36hours or something. like we have to give a presentation to larry ellison. and we werelike okay. they wanted to mock their app. not because their app didn't work but becauseit's not a real time app. it's something that takes weeks to get the full experience outof. it's data mining, analytics type thing. and so they wanted to make a canned presentationbut in html so you could interact with it.

they didn't want power point animations, theyreally wanted to be able to play with it to be able to experience what it did. brent: in 36 hours? ara: maybe we had... i guess it was fridayand we had to deliver on monday morning, so it was a little longer than that. but yeah,three days. some reason 36 hours came to mind. anyways. maybe 36 hours of work might havebeen what it was, in three days. and anyways they told us, it's on chrome. because we toldthem we need to know the platform with this kind of time. we are not testing in any otherbrowser. we need to know the version, the os, everything. like okay, definitely it'sa mac laptop, definitely chrome. and we hung

up the phone and i looked at steve, we workedon this together. and i was like yeah bull[explicit]. there's no way that we can rely on that. sowe just made it responsive and made it work in any web browser basically. it was funnybecause on monday morning they called us in a panic. oh my gosh, we have to give the presentationon an ipad. this terrible, the whole thing! and we're like it's no big deal, it's fine.and they're like really? yeah. and that hasn't changed. it actually perplexes me that peoplethink that there's anything new going on in the internet right now, it's all old. brent: it sounds like you can get out of theweave a little a little bit and see that pattern over your tenure. and that's probably veryimportant to not get so caught up in like

every blog post coming out every day withsome new tweak or something. making it exciting or some launch that's like this is the bestthing in the world. and then having to get perspective on that. ara: yeah. perspective, although i think theimplication there is that somehow it's related to experience or age. and i've noticed inmy time working with other developers that there's really only two kinds of developers.i mean there's young guys, they come out of school. i was a young guy who came out ofschool, work with other guys who came out of school that studied hard. that are reallycomputer scientists. and if you understand what a touring machine is, what limits onmemory. what's the difference between a sequential

scan and seeking all over the disc while you'redoing data processing? like what is swap? these things are... what is the cap theorem?you know, like it's actually important if you're an internet developer. and a lot ofpeople were asleep in class or just fundamentally don't understand the law of computing. andi don't think that really has anything to do with tenure or experience. i think youeither get it or you don't. and i think about 1% of developers get it. and if you don't,combine with the proliferation of information out there. that is also a change, right? getub[sp]and other blogs. i mean there's usually stack overflow, twitter... gah make it stop already. brent: you could get pretty far knowing verylittle.

ara: i don't think so. i really don't. i meanit think it appears that way. but if you look at the... if you chart the trajectory of developersand companies and software projects. a large majority of them is probably the 80-20 rulelike most things. a large majority of them they grow and grow and grow and they hit aglass ceiling and they collapse. software does this. developers come into companies,they build things, they build things, they build things. and in about three years, teamsusually get to a spot if there's not a lot of churn where suddenly they're not developingnew things they're just maintaining the crap that they wrote. they start to hate it, thecompany starts to experience churn, it goes on the decline. i see that everywhere. i meanyou see it in start ups, you see it in fortune

5,000 companies. you see it in developersin their development career. they start getting that three year itch. like what language shouldi learn now? like that's going to change anything. like they're touring complete, enough already.you're typing system. like none of this matters. it's a touring machine. live with it, theyall suck a lot. to solve the problems that we're trying to do, to solve the problemsthat we're trying to solve, our tooling is still totally inadequate. it's just terribleas a field. the tools that we have to use to create the solutions we need to create.they're pathetic. so yeah. anyways, i don't think that that's true. and i think there'sgoing to be a backlash in the field now too. i mean i think right now in the developmentworld... in the start up world with developers

with people who are investing money in startups, there's a sense of inflation of ego, of value, of worth. of the difficulty or importanceof what we're doing. and i think that creates a market where people that don't really knowwhat they're doing... and they may be making six figures. the company may be generatingrevenue. but i don't think, if we look at the industry as a whole, in ten years likei don't think we'll be able to asset that you'll be able to learn how to program inseven weeks and build companies that provide lasting value and enduring revenue for theeconomy. i don't think that's true. brent: for sure. what kind of... i mean asa hardcore developer, what kind of practices have you kept over time? whether it's somethingyou do daily or weekly or monthly that's really

made an impact on your profession? ara: yeah. lots. i think about this a lot.i'm not a productivity nerd. i mean i think a lot of... there's sort of two categoriesof practices that i think about. and the biggest set of practices are mental, i think. or emotional.or they're internal. they're internal practices. so things like i just actually sent a letterto my group this morning, i was doing a code review. and like understanding the problem.it's a huge thing that somehow... and if you get two engineers in a room and you say vimand emax or node and rails or whatever. and like everybody will be frothing at the mouthtalking about the minutia. about the tooling they're using and about a bunch of shit thatdoesn't matter. but if you start asking meaningful

questions about the domain you're in, theproblem that you're solving, nobody has anything to say. very few people do. there are a fewpeople, and they're the engineers that go build their own start ups. and they understoodthat there was a problem, and they built a solution to it. and they have billions ofusers. i mean that's why that happens. but it's rare that somebody actually takes thetime to understand problems. and i, again, this is something that... it depends on yourengineering school. you certainly don't have to go to engineering school to learn this,but it's something that people innately have when they come into programming. or learninganything new. like if they're problem solvers, which is what we are, then the very firstthing you need to do to solve a problem is

to understand it completely. and that's justoverlooked. i mean ten times a day by every developer and every shop i've ever been in.is this the actual problem that i'm trying to solve? so that's one. not taking thingstoo seriously. i mean i have a great disdain for people arguing around whiteboards. i'mjust categorically uninterested in doing that ever again in my life. like i like to avoidthose kinds of people, i like to avoid those kinds of clients. so just keeping perspectiveon what we're doing. it's like sometimes you're working with software where it's real timesoftware, controls a satellite. it's like it costs $250,000 for a little processor thatthey seal in plastic in there, like this is serious business. but most of the stuff wedo is totally not serious. it's not worth

getting upset about. it's just not that important.and so trying to keep a light heart, understanding what we're doing, trying to keep a light heart,i think that's a big one. in terms of like mechanical processes, i guess overall i havea minimalist philosophy. so like my phone is, i'm right where a mobile shop. and theseare the apps that i use. brent: you have a very un-cluttered app screen. ara: i have a calender. and they're all work.i guess as one practice, i never do entertainment on computers. i don't read on them, i don't...occasionally i'll watch a movie. it's very rare. i certainly don't play games. i don'tinstall lots of apps and mess with them. i try to make things, i try to spend my energythere. so that's... i think that can be draining

when you're on a screen all day and then yougo home and you're looking at screens, it's not good for your creativity. so i try tobe minimalist with my tooling, and that goes across the boards. so my ide is and has beenfor as long as i've been using a computer, almost 20 years now, it's vim. i use vim ina terminal. my development environment on the mac is identical to the one on linux isidentical to the one on windows. it's identical if i'm ssh'ed in or on my desktop it's likethe black screen, it's vim. it works with every language known to man, it's very fast.so those are the biggest things, i think. it's trying to be very minimalist about mytooling and sort of open minded and relaxed just about the actual work that i'm doing.and then i guess the last sort of major practice

that i have is that i hate doing things...okay twice i can handle it. three times, i can't handle it. and it shocks me that developersthemselves, they will do something. like i've done this five times. and it's like there'sonly one thing that computers are good at. and it's automating things in a precise way.predictable things. that's all they can do, right? they can't think. they can follow instructions.and it shocks me to see developers who will be writing a solution that's similar to onethat they did three months ago. and it's like why didn't... and there's two reasons whypeople do that. the biggest one is probably laziness. but the second one i believe comesback to not understanding the problem. because if you can understand a problem and describeit, it's usually not that hard to make it

an abstraction that you can re use if youunderstand it. the solution is sort of obvious. it's like i just need 100 lines of javascriptin a library and i won't have to do this again. so that's one thing is i make lots of abstractions.i probably have... i mean i have thousands of scripts that i rely on every day. i haverobots that are running out of the clouds that do thing for me. and then libraries andthen golden image applications that i can clone. automating things and abstracting thingsis the only way that you can sort of build value as your inherent value. because youcan only type so fast. but when you can come to the table with solutions to problems thatyou've seen before, abstractions, you become more valuable over time. and you can get morethings done. and you can, more importantly,

solve increasing complex problems with thesame ease that you were able to ten years ago. because you have a war chest. brent: very cool. well ara, this has beenincredibly fascinating. definitely hope you can join us again some time in the future.give us maybe an update or maybe we'll have you on a panel. i think you've got some goodstrong opinions which we appreciate. ara: great. yeah i really enjoyed it. brent: very cool. well stay tuned for moregreat content from ugurus.com.