Lazycoder.com - Part 3

23Sep/11Off

Herding Code 121: Sara Chipps updates us on Girl Develop It at one year

This episode of Herding Code Kevin and Jon catch up with Sara Chipps to find out how Girl Develop It is going.

Kevin jumps right into it by asking Sara about what’s been going on over the past year. Sara goes back to what was on their minds as they were first getting started with their first class, and how that’s grown to 6 cities worldwide, and their original New York chapter offers 20 classes a month with 5 teachers.
Kevin asks where the other teachers came from, and Sara spins a tall tale about flamethrower classes. Well, maybe it’s true, but I find it a bit suspect.
Kevin asks about where the classes are held.
Jon asks about how the money part works out. Sara explains how the class fees, donations, and teacher payments all work out.
Kevin asks Sara about about what tools they teach, and Sara mentions Aptana.
Jon asks for some success stories and Sara tells a few.
Kevin asks how many students go through several classes; Sara says they see about 25% frequent fliers.
Jon asks if there’s some measurement of how much the students actually learn. Sara explains that the classes include a good amount of hands-on work and homework, and that she and the other teachers continue to learn how to gage when students are getting lost.
Kevin asks if there are some students that just don’t get it, and Sara says that some students have a tough time understanding that a single missing character can break a whole program. Everyone commiserates about this fun part of software development. Jon speculates that young women may be missing out on some of the split between cold logic and reason because they don’t play enough video games.
Jon notes that a lot of real world computer programming involves problem solving and support network and asks if students are equipped with those things. Sara talks about how anyone watching her code will see a good amount of debugging; additionally she teaches students about how to use StackOverflow so they can get their questions solved.
Kevin asks how the curriculum and courses have evolved over the past year. Sara and Jon talk about the amount of time and effort involved in preparing decent training materials.
Kevin asks about changes in teaching approach over the course of the past year. Sara said she’s moved from code-only to using some slides, and that when writing code it’s important to walk through it in pretty good detail.
Kevin asks what’s been different from expectations, and Sara talks about both the amount of interest and community goodwill.
Kevin asks about how Girl Develop It has spread to other cities, and asks about how much of the content is shared between cities.
Jon asks about how the branding and design is handled.
Jon asks if there are advanced classes or seminars.
Jon asks Sara what sort of projects she’s been working on lately. Sara says it’s pretty much all Javascript lately.
Kevin asks if there will be a node.js class (drink!)
Kevin asks what’s next for Girl Develop It, which prompts Sara to talk about the first Girl Develop It hack-a-thon. Apparently these are like a guy hack-a-thon except with less pizza and body odor and more resort and catering.
Kevin asks if Girl Develop It could develop into a full time gig. Sara says that all the leaders love developing and don’t want to give that up, so they’re still trying to figure that out.
Jon asks how listeners can support Girl Develop It. Sara lists a range of options, including book, laptop donations, and meeting space. Kevin asks about cash contributions.
Jon and Kevin note that there are no West Coast US branches. Sara mentions that a bay area location may start soon.
Kevin asks about the 15% male attendance in Girl Develop It, and Sara explains how that works.
Jon asks if there’s potential for virtual events and video recordings. Sara explains that, while it sounds great logistically, it misses out on a lot of the most important aspects of the Girl Develop It classroom experience. They’ve got trial running in the Columbus branch, though, so they’ll see how it goes.
Sara teases about an interesting hack-a-thon project they did recently using the Aviary API’s called Stash Your Stash, which removes moustaches from photos because "they’re super creepy!"

Show Links:

Download / Listen:

Herding Code 121: Sara Chipps updates us on Girl Develop It at one year

Tagged as: herdingcode, podcast Comments Off

12Sep/11Off

Herding Code 120: Ryan Stewart on RIAs and All Things Adobe

This episode of Herding Code the guys talk to Ryan Stewart, a developer evangelist at Adobe.

Scott K asks about the pricing of Adobe products. Ryan explains why things are priced as they are and talks about the subscription model alternative.
Jon talks about the open other free or inexpensive alternatives for beginning Adobe development since the formats are generally open sourced. Ryan agrees and also explains that Adobe’s entire pricing model is built around tools, whereas Microsoft’s includes both tools and servers.
Jon asks about the licensing around Flash Media Server. Ryan explains that it’s not something general developers will need to deal with.
Scott K speculates around the idea of appliances from Adobe which would be complete video / media processing systems. Ryan says he thinks that’s interesting but he doesn’t expect anything like that to happen.
Jon asks about the general trends away from some rich internet abuses in the past. Ryan and Jon talk about the polyfill approach for using Flash and RIA technologies to augment browsers when the features aren’t supported. Ryan and Scott K talk about how developers and the tech press have quickly forgotten that many of the new emerging browser capabilities (typography, media, animation) are modeled after capabilities that RIA technologies initially pioneered.
Scott K points out that this is a good segue to the new Edge tool. Ryan talks about how Edge is a designer tool that creates CSS3 and JavaScript animation using the timeline that Flash designers are used to. Jon mentions that this makes more sense to him when thinking about Adobe primarily as a developer tools company rather than a platform oriented company.
Jon asks about Adobe support for HTML5 / CSS3 development in Edge with Flash fallback. Ryan talks about how they generally keep them separate, and if browser-based animation isn’t supported it just won’t play.
Kevin asks about how Edge affects the accessibility of the underlying content.
Jon asks about how Flash Builder 4.5 allows for developing native iOS and Android applications. Ryan explains how it works and clarifies how it complies with Apple developer guidelines. There’s a mention of the popular Mono apps which run on iOS.
Twitter question from Chris Edwards: "What are the are the best tools for automated testing of Flash UI’s" – Ryan recommends HP Quick Test Pro
Scott K asks about Adobe Air – it seemed great, but seems to have kind of fallen out of favor. What’s the deal there? Ryan talks about how Air was both a great, bold idea, but also a new challenge for Adobe, in that Air applications are much longer running than most Flash apps.
Jon asks about some annoyances in installing updates for Air, Flash, etc. Ryan explains some of the reasons for the updates. Jon asks about the possibility to add in more of an auto-update experience.
Jon asks Ryan about some of the new features in Flash. Ryan talks about a lot of features, including Stage Video and 3D GPU support and graphics features. Scott K. asks if there are opportunities for leveraging WebGL, and Ryan says that there have been discussions about that but nothing’s in progress yet.
Ryan asks the guys what they’re expecting at at BUILD, and they all clam up. Scott K. ask about Flash on Windows Phone. Ryan says it’d be great, but he’d be surprised given the Silverlight support on Windows Phone. Kevin’s happy that speculation will finally stop. Scott K. talks it’s good that developers are having to care about memory and CPU usage again.
Ryan talks about the difficulty of bringing richness and creativity to the client without adversely impacting performance.
Scott K asks about the current state of Adobe Labs. Ryan points out that the Adobe MAX conference is coming up in October, so Labs will probably be pretty quiet until then.
Jon asks about Muse. Ryan explains that really targeted at print designers who want to create web content, so it’s not really a tool for web designers or developers.
Jon asks about some Adobe client products which are developed in Air.
Scott K. asks about what big surprises may be happening at MAX this year. Ryan and and Scott K. speculate a bit more about BUILD, and Ryan tells listeners who recognize him at BUILD to please say hi. Jon says he might sneak in if he can locate a catering costume.

Show Links:

Download / Listen:

Herding Code 120: Ryan Stewart on RIAs and all things Adobe

Tagged as: herdingcode, podcast Comments Off

26Aug/11Off

Herding Code 119: On The Writing Technical Books (with Jesse Liberty, Phil Haack, and Brad Wilson)

This episode of Herding Code the guys talk to Jesse Liberty, Phil Haack, and Brad Wilson about writing technical books. Jesse has written dozens of technical books, and both Brad and Phil worked with Jon and K. Scott on the recently released ASP.NET Professional MVC 3 book. What’s it like to write a book? Why do it at all? How does the process work? How is it changing? Is Angry Birds your favorite story? Join us for a very literary version of Herding Code to find out.

We start with a listener question from @tpdorsey (Terrence Dorsey): “*Printed* books? If so, why bother? I ask this as a print writer and editor for 17 of last 20 years.”
There’s a discussion of the value that the editorial process adds to books as compared to blog posts.
Twitter question from @schwarty: “Best way to work a first time deal? Submit queries? Try to team up with co-writers?” Phil, Brad, Jon, K. Scott, and Jesse tell stories about how they got their first book deals.
Phil notes that most authors get a start in other mediums – blogs, magazines, possibly StackOverflow in the future.
Jesse talks about his investigation of self-publishing. In the end, he decided that the editorial process tipped the scales towards working with a publishing company.
Jon references Twitter questions from @devhammer and @jglozano on dealing with procrastination, making time to write, etc. He points to positive pressure of working for a publisher under a schedule and a contract to get the book out the door. Brad talks about how peer pressure from other authors to keep up is also helpful.
There’s discussion about the challenge writing up an outline before starting the book. Phil talks about how the publishing industry in general is pretty stuck on older technologies like FTP, and in general the process feels like waterfall software development.
Jesse says that if you’re reasonably on schedule, publishers are pretty flexible about changes to the outline.
Brad answers listener questions from @stevenproctor “Have you found e-readers coming into their own to influence how you think about book?” and “has it changed how you think about layout/presentation for cross format reading” saying that it was difficult to write without seeing what the end result would look like, but he was very happy when he saw the end result, both in print and the e-book format.
Jon talks about how working with book templates from various publishers has taught him to appreciate the use of styles in Word, explaining a case where he was able to search for code snippets based on the styles that were used.
Kevin asks some interesting questions about whether working on the book puts pressures on when to ship the product, and whether writing a book about a product points out features that should be changed. Brad explains that the king of product changes due to writing (blogging in this case) is Scott Guthrie.
Phil talks about how Eilon (the technical reviewer) was good at keeping him from digging too far into minute details that nobody would care about. Jon explains that Eilon pointed out that the Controllers chapter was going way into the weeds before actually showing the most common use case, and Brad says that he’s in good company with an example from Charles Petzold’s book on Windows programming.
Jon talks about the tricky chicken-and-egg situation with trying to explain the MVC pattern in depth, since an in-depth explanation of the Model, View, and Controller requires an in-depth understanding of the other components. Jon asks Jesse about how he handles that, and Jesse talks about the importance of having a model user and getting volunteer readers as you’re writing.
Jon talks about the benefit of working with other authors. Brad talks about the this is more important with products with quick release cycles, and Phil compares book writing with software development techniques.
There’s a discussion on ensuring a consistent voice in a book with more than one author.
Phil, Jon, and Brad discuss the conflict between beginner and advanced content. Are the experts who are asking for advanced content representative of most readers? Phil points out that writing advanced content is a lot more fun, but limits the audience. Can a book please everyone? Is there a way to include beginner and advanced content? Jesse describes some ways he handles this, and says that it’s important to set expectations.
Jon talks about the decision to remove NerdDinner, referring instead to the MVC Music Store tutorial.
Jesse says that it’s remarkable that books are still selling well, since they’re competing with blogs, tutorials, videos, etc. He speculates that the main selling point for books now is in context: telling a story. Jon asks how he manages to do that.
Phil talks about the decision to put all the book’s code samples in NuGet (triggering the Haacked NuGet Drinking Game clause).
Jesse talks about the mismatch between the publisher’s requirements for a flow of completed chapters and the software developer’s desire to refactor.
Jon asks K. Scott how writing magazine articles compares to writing for a book.
That’s pretty much it.

Show Links:

Jesse Liberty (@jesseliberty)
Phil Haack (@haacked)
Brad Wilson (@bradwilson)
Professional ASP.NET MVC 3 on Amazon and at Wrox.com
Jesse’s dozens of books on Amazon
Eilon Lipton

Download / Listen:

Herding Code 118: On The Writing Technical Books (with Jesse Liberty, Phil Haack, and Brad Wilson)

Tagged as: herdingcode, podcast Comments Off

26Aug/11Off

Herding Code 119: On The Writing Of Technical Books (with Jesse Liberty, Phil Haack, and Brad Wilson)

We start with a listener question from @tpdorsey (Terrence Dorsey): "*Printed* books? If so, why bother? I ask this as a print writer and editor for 17 of last 20 years."
There’s a discussion of the value that the editorial process adds to books as compared to blog posts.
Twitter question from @schwarty: "Best way to work a first time deal? Submit queries? Try to team up with co-writers?" Phil, Brad, Jon, K. Scott, and Jesse tell stories about how they got their first book deals.
Phil notes that most authors get a start in other mediums – blogs, magazines, possibly StackOverflow in the future.
Jesse talks about his investigation of self-publishing. In the end, he decided that the editorial process tipped the scales towards working with a publishing company.
Jon references Twitter questions from @devhammer and @jglozano on dealing with procrastination, making time to write, etc. He points to positive pressure of working for a publisher under a schedule and a contract to get the book out the door. Brad talks about how peer pressure from other authors to keep up is also helpful.
There’s discussion about the challenge writing up an outline before starting the book. Phil talks about how the publishing industry in general is pretty stuck on older technologies like FTP, and in general the process feels like waterfall software development.
Jesse says that if you’re reasonably on schedule, publishers are pretty flexible about changes to the outline.
Brad answers listener questions from @stevenproctor "Have you found e-readers coming into their own to influence how you think about book?" and "has it changed how you think about layout/presentation for cross format reading" saying that it was difficult to write without seeing what the end result would look like, but he was very happy when he saw the end result, both in print and the e-book format.
Jon talks about how working with book templates from various publishers has taught him to appreciate the use of styles in Word, explaining a case where he was able to search for code snippets based on the styles that were used.
Kevin asks some interesting questions about whether working on the book puts pressures on when to ship the product, and whether writing a book about a product points out features that should be changed. Brad explains that the king of product changes due to writing (blogging in this case) is Scott Guthrie.
Phil talks about how Eilon (the technical reviewer) was good at keeping him from digging too far into minute details that nobody would care about. Jon explains that Eilon pointed out that the Controllers chapter was going way into the weeds before actually showing the most common use case, and Brad says that he’s in good company with an example from Charles Petzold’s book on Windows programming.
Jon talks about the tricky chicken-and-egg situation with trying to explain the MVC pattern in depth, since an in-depth explanation of the Model, View, and Controller requires an in-depth understanding of the other components. Jon asks Jesse about how he handles that, and Jesse talks about the importance of having a model user and getting volunteer readers as you’re writing.
Jon talks about the benefit of working with other authors. Brad talks about the this is more important with products with quick release cycles, and Phil compares book writing with software development techniques.
There’s a discussion on ensuring a consistent voice in a book with more than one author.
Phil, Jon, and Brad discuss the conflict between beginner and advanced content. Are the experts who are asking for advanced content representative of most readers? Phil points out that writing advanced content is a lot more fun, but limits the audience. Can a book please everyone? Is there a way to include beginner and advanced content? Jesse describes some ways he handles this, and says that it’s important to set expectations.
Jon talks about the decision to remove NerdDinner, referring instead to the MVC Music Store tutorial.
Jesse says that it’s remarkable that books are still selling well, since they’re competing with blogs, tutorials, videos, etc. He speculates that the main selling point for books now is in context: telling a story. Jon asks how he manages to do that.
Phil talks about the decision to put all the book’s code samples in NuGet (triggering the Haacked NuGet Drinking Game clause).
Jesse talks about the mismatch between the publisher’s requirements for a flow of completed chapters and the software developer’s desire to refactor.
Jon asks K. Scott how writing magazine articles compares to writing for a book.
That’s pretty much it.

Show Links:

Jesse Liberty (@jesseliberty)
Phil Haack (@haacked)
Brad Wilson (@bradwilson)
Professional ASP.NET MVC 3 on Amazon and at Wrox.com
Jesse’s dozens of books on Amazon
Eilon Lipton

Download / Listen:

Herding Code 118: On The Writing Technical Books (with Jesse Liberty, Phil Haack, and Brad Wilson)

Tagged as: herdingcode, podcast Comments Off

26Aug/11Off

Herding Code 119: On The Writing Of Technical Books (with Jesse Liberty, Phil Haack, and Brad Wilson)

We start with a listener question from @tpdorsey (Terrence Dorsey): "*Printed* books? If so, why bother? I ask this as a print writer and editor for 17 of last 20 years."
There’s a discussion of the value that the editorial process adds to books as compared to blog posts.
Twitter question from @schwarty: "Best way to work a first time deal? Submit queries? Try to team up with co-writers?" Phil, Brad, Jon, K. Scott, and Jesse tell stories about how they got their first book deals.
Phil notes that most authors get a start in other mediums – blogs, magazines, possibly StackOverflow in the future.
Jesse talks about his investigation of self-publishing. In the end, he decided that the editorial process tipped the scales towards working with a publishing company.
Jon references Twitter questions from @devhammer and @jglozano on dealing with procrastination, making time to write, etc. He points to positive pressure of working for a publisher under a schedule and a contract to get the book out the door. Brad talks about how peer pressure from other authors to keep up is also helpful.
There’s discussion about the challenge writing up an outline before starting the book. Phil talks about how the publishing industry in general is pretty stuck on older technologies like FTP, and in general the process feels like waterfall software development.
Jesse says that if you’re reasonably on schedule, publishers are pretty flexible about changes to the outline.
Brad answers listener questions from @stevenproctor "Have you found e-readers coming into their own to influence how you think about book?" and "has it changed how you think about layout/presentation for cross format reading" saying that it was difficult to write without seeing what the end result would look like, but he was very happy when he saw the end result, both in print and the e-book format.
Jon talks about how working with book templates from various publishers has taught him to appreciate the use of styles in Word, explaining a case where he was able to search for code snippets based on the styles that were used.
Kevin asks some interesting questions about whether working on the book puts pressures on when to ship the product, and whether writing a book about a product points out features that should be changed. Brad explains that the king of product changes due to writing (blogging in this case) is Scott Guthrie.
Phil talks about how Eilon (the technical reviewer) was good at keeping him from digging too far into minute details that nobody would care about. Jon explains that Eilon pointed out that the Controllers chapter was going way into the weeds before actually showing the most common use case, and Brad says that he’s in good company with an example from Charles Petzold’s book on Windows programming.
Jon talks about the tricky chicken-and-egg situation with trying to explain the MVC pattern in depth, since an in-depth explanation of the Model, View, and Controller requires an in-depth understanding of the other components. Jon asks Jesse about how he handles that, and Jesse talks about the importance of having a model user and getting volunteer readers as you’re writing.
Jon talks about the benefit of working with other authors. Brad talks about the this is more important with products with quick release cycles, and Phil compares book writing with software development techniques.
There’s a discussion on ensuring a consistent voice in a book with more than one author.
Phil, Jon, and Brad discuss the conflict between beginner and advanced content. Are the experts who are asking for advanced content representative of most readers? Phil points out that writing advanced content is a lot more fun, but limits the audience. Can a book please everyone? Is there a way to include beginner and advanced content? Jesse describes some ways he handles this, and says that it’s important to set expectations.
Jon talks about the decision to remove NerdDinner, referring instead to the MVC Music Store tutorial.
Jesse says that it’s remarkable that books are still selling well, since they’re competing with blogs, tutorials, videos, etc. He speculates that the main selling point for books now is in context: telling a story. Jon asks how he manages to do that.
Phil talks about the decision to put all the book’s code samples in NuGet (triggering the Haacked NuGet Drinking Game clause).
Jesse talks about the mismatch between the publisher’s requirements for a flow of completed chapters and the software developer’s desire to refactor.
Jon asks K. Scott how writing magazine articles compares to writing for a book.
That’s pretty much it.

Show Links:

Jesse Liberty (@jesseliberty)
Phil Haack (@haacked)
Brad Wilson (@bradwilson)
Professional ASP.NET MVC 3 on Amazon and at Wrox.com
Jesse’s dozens of books on Amazon
Eilon Lipton

Download / Listen:

Herding Code 118: On The Writing Technical Books (with Jesse Liberty, Phil Haack, and Brad Wilson)

Tagged as: herdingcode, podcast Comments Off

24Aug/118

How we learn to write code

Great post titled “Your code is my hell” describing some particular problems with Ruby and Rails projects.

One thing that is brought up in the comments that I wanted to expand the discussion on is how universities teach programming.

I blame the education system for developers. Shockingly few universities and colleges deal with the “why” of programming, only the “how”, and almost all seem more focused on the tuition money coming in rather than the quality of education going out. The only programmers worth a damn anymore are the ones who taught themselves from youth, and we’re outnumbered by the 9-to-5ers churned out by higher education.

I think the “why” of programming can’t really be taught, or at least it is miscommunicated. The “why” is often thought of in terms of features or user needs. These needs do have to be considered, and “git ‘er done” is valid thinking. But maybe it should be expanded to “git ‘er done right”.

The “why” of programming can also be thought of in terms of developers and maintainers needs. Why do we need unit tests? So people who come after us, including us a few years from now, who have to work on this code can tell if something breaks when they make a change without having to wait for QA or the users to tell them.

Mostly it seems like we learn to program by working on new, or greenfield, projects. All the classroom assignments start with creating a brand new project with well defined requirements. All the sample code put out by Microsoft, Apple, Google, and others assumes the same starting point. While it is important to start new projects, most of the code you will work on as a professional developer, in my experience, is NOT written by you from scratch.

Maybe young developers and university students would benefit more from joining an internship program? Or maybe university CS departments could function as consultants or “offshore” firms and provide low-cost temporary employees to firms, killing two birds with one stone.