201 karma · joined April 18, 2009
Try moving your pointer around to different positions very close to the top right corner. This triggers a picture with a wristwatch and water bottle. The pointing is done by the right hand, which if your pointer is too far right is cut out of the frame, but becomes visible as you move towards the left.
If you don't see anything, try disabling social-blocking extensions.
The content team (teachers, video, audio, motion design) is a sizable portion of the company. They focus on writing, producing, and supporting the learning content and video.
The app team (devs + designers) focus on things like the the web app, the learning tools like our code challenges, and quite a bit of other stuff.
We have support team members who are always interacting with and helping our students. Marketing, sales, and operations are doing what you would expect them to.
It's interesting to watch the scaling in person. When I started it was just Nick Pettit and myself as teachers ( and we did our own video/audio work), Ryan the CEO, and we had a contract dev and designer. Now it's ~60, not even sure of the exact number, and everyone keeps really busy.
Remember the registry deals with the actual data, and delegates auth and other stuff to an index. The docker-registry has a dummy implementation of an index that has no notion of authentication or authorization, so anything you push to your private registry is really public if you don't secure it with some other method.
For me, I wanted to have a real private registry with access control limited to my team. It turned out to not be too difficult to make our own registry+index implementation that is private by default. It has a basic web interface too. I've open sourced development of it https://github.com/jimrhoskins/stevedore . It's still really rough, especially on the web interface stuff, but for push/pull operations with required authentication, it does the job now.
Telescope was my favorite of the choices I saw. Great work.
We also has a lot of emails about interesting articles about our company, or the space we're in. Sometimes discussions would happen in email, and not being well threaded it was hard to follow. Also those emails are not usually actionable, but they appear in your inbox.
We post a lot of interesting links in convoy, as well as all the above categories of conversation. It definitely has more of a reddit feel than a HN feel. It's not a work-only type of environment. We have fun. Since the video team has hours of video of the teachers, they have this habbit of making embarrassing animated gifs and posting them, which is fun.
We don't really have rules about what you CAN post in convoy, we have guidelines about what you SHOULDN'T put in email. If it's not a good convoy post, votes will take care of it.
Why not discourse/reddit/telescope/etc...? I looked into those. Solving the problem we needed a few basic things, posts, threaded comments, and votes. The killer feature that we wanted it to be private to our company, and we wanted authentication integrated with http://teamtreehouse.com. Hacking any existing solutions to fit that auth model seemed more work than it was worth.
When it comes down to it, it's a ridiculously simple app. There's a few models, and not a whole lot of code. When we gauged the effort of integrating most of the OS solutions into our oauth system and locking it down to be in-company only, just making the app was way easier. Plus. we can easily extend it to fit our needs, and we have. Also, I wanted to play w/ rails 4 + ruby 2 for the first time.
Regarding the name, it was a code name. The tool is built for having conversations (convos), and I though convoy was a cool codename. As soon as Ryan saw my working prototype, he told me to launch it, and the name stuck. I didn't even know there was a movie.
All three of them (angular-ui, ui.bootstrap, angular-strap) have been a pleasure to work with.
I write a lot of hobby/side projects just for experimenting and learning, and Angular has become my framework of choice. You can just get stuff done so quickly and easily, particularly after you've been using it for a while.
Angular has a sort of jagged learning curve. It's shallow for quite a while, and you can do a lot of work in that shallow half. However once you need to start writing your own directives, the curve steepens. It's not the steepest curve, but there's definitely a transition. This is when you hear people talking about Angular being difficult, citing things like transclusion.
I've made it to the other side of the curve, and I love writing directives and services, it's become fairly intuitive to me. With the modular architecture, if you there is a large library of available modules/plugins, even people who don't want to write a lot of JS and understand Angular to it's core can do some amazing things. That's why I built http://ngmodules.org , so that people can share modules, and AngularJS can be accessible to more people.
All of the lessons learned in your article are really good ones, particularly about reading documentation, and even copying code at first. It's something we struggle with at Treehouse, we want our courses to be as smooth and error free as possible, but it's a bit disingenuous to portray building an app as something so smooth.
Developers encounter errors, Google error messages, and dig through docs all the time. We're trying to integrate some of the bugs we encounter into the videos, to hopefully shed some insight onto how to troubleshoot when errors inevitably occur.
The team that manages the web app, and most of the other teams, are small in comparison, they are certainly small and effective teams that utilize automation.
I agree with your points on automation, I just wanted to point out there are still things that require human interaction and creativity to produce.
I put together http://ngmodules.org/ as a searchable repository of Angular Modules. Hopefully people will find some useful libraries through it.
Might be good to have something show up in case you can't reach facebook.
Before you say that it should be just a line, let me say that it doesn't break the rules that say you can "draw" a circle with 100 or 12 or 7 dots. The dots don't form a circle but rather fall on the line of a circle your mind draws. Since there is nothing truly between the dots, the "true" shape could jut out and form a corner or any other shape, just like it could be a line between the two dots. The circle isn't really there in any circle of n points, so n=2 (and n=1 for that matter) work just fine.
I think you should at least mention the other "letters" included in the library on the front page. It goes in depth into 'p', which makes it seem like it's all there is. Maybe name some of the other letters, and link to the API docs.
Each individual piece seems pretty small and easy enough to implement, but the package as a whole seems more valuable, having all these little tools in one place.
Nice work
Perhaps donating money to a charity or political party you don't agree with would be more motivating.
I don't say that with any bitterness. I have and love my air, but as I find myself using less and less of OS X, and really just living in iTerm and my browser, the real appeal of the Air to me now is the hardware. If the Ultrabook stands up to the Air in quality, I'm seriously considering the Ultrabook + Ubuntu (double-u?) for my next notebook. Also assuming Ubuntu runs well on it, which my guess is if it doesn't now, it will soon.
I teach programming through video courses, and at a very beginner level, you have to lie a lot, in order to simplify the concepts that are peripheral to the core concept you are trying to explain. There are few things (if any) in the world that can be explained linearly. The dependency graph for any concept you want to teach will branch out into a dozen other topics, and often cycle back on itself.
The way you have to teach is pick a core concept you want your student to learn, and do your best to explain it, and whenever an unexplained concept comes up, explain it the simplest way you can so you don't get knocked off track. Often this involves lying, or creating the simplest mental model that works for the current situation.
I'll get emails routinely from people who say that I didn't thoroughly explain some topic that was not the core topic of the exercise. For instance if you want to learn about JavaScript strings, you may want to mention "string".toUpperCase(), but if you are just learning about strings, functions or method invocations are some way off in the future. You can't just stop and explain the details of functions, how they are invoked on objects if you are still working on the basics of a core data type.
So the hardest thing is not just knowing when to lie, but how to lie in a way that won't cause too much upset if the student knows you are lying. The best way to mitigate this is to explain that it is a simplification, and we will learn more about it soon. This is usually enough to keep going, as well as keep interest levels high.