Don’t Check Your Email in the Morning
An interesting idea from Scott Hanselman.
DON’T CHECK YOUR EMAIL IN THE MORNING.
Insane right? I believe that checking your email in the morning is the best way to time-travel to after lunch.
Why DO we check email first thing in the morning? Well, because something crucial might have happened overnight.
There’s a few things wrong with that sentence, in my opinion. Words like “something” and “might” stick out. We check our email because of fear, a sense of disconnectedness, and (in some cases) a feeling of urgency addiction.
I think this is worth trying at least once, if you aren’t me. Me, I’ve tried this before. I find that I am WAY more productive in the afternoon and evening than I am in the morning. I’ve always hated the “9-5″ workday. I find that I can’t get started and focused on a project before lunch regardless of whether I’m on IM or checking emails. There’s just something about my brain that doesn’t start working until the afternoon.
My general workflow is to check email first thing, respond if necessary, filter out the worthless emails, accept meeting requests, etc… Then I CLOSE my email client and don’t open it back up until just before I leave. Sometimes I’ll check email just before lunch if I’m waiting for a reply from someone. I do agree with Scott’s general point, don’t get so caught up in your inbox that you lose focus on the actual reason you are at work. And, as always, postpone meetings with time wasting morons.
The guys talk to Michael Mahemoff about Player FM, a cloud based podcast application which is focused on discovery and multi-device synchronization that he recently showed off at Google I/O.
Download / Listen: Herding Code 195: Michael Mahemoff on Player FM
- Hello. What is Player FM?
- (00:48) K Scott asks Mike for a quick introduction. Mike has studies both psychology and software engineering and has worked on a variety of applications, focusing lately on HTML5 web applications. He’s been working for the past few years on Player FM, a cloud based podcast application which is focused on discovery and multi-device synchronization.
- (01:55) K Scott asks about the technologies used to build Player FM. Mike talks about the advantages of moving feed fetching to the cloud, the web site (using a PJAX implementation which pushes markup rather than data and HTML5 history) and an API.
- Player FM API
- (04:33) K Scott asks more about the API. The server is running Ruby on Rails using controllers that supply different format based on the extension in URL. The API is publicly available for experimentation but isn’t officially supported. Mike’s set up using a spectrum of detail levels (none, id, medium and full) rather than allowing clients to select specific fields. This allows you to be efficient in your API requests for hierarchies but is still cachable. He’s created a framework to support that.
- (09:10) Jon mentions some of the URLs he’s seeing in browsing the API for listeners who want to play along at home. He asks Mike about the balance of a self documenting API vs the full hypermedia smart client approach. Mike says he thinks the API needs to be pretty mature for that to work and points out some of the curated lists in the feed.
- (11:33) K Scott asks if the curation is community based. Mike says that’s the eventual goal, but for now he’s doing that.
- (12:23) K Scott asks about the difficulty in tracking when all the feeds have been last updated. Mike says that originally it was a simple loop using feedzilla. Now it’s using sidekick and the PubSubHubbub standard (using the superfeeder service and webhooks). The clients are still polling now, but he’s going to be updating the clients to use Google Cloud Messaging (on Android) and iCloud Messaging (on Apple) so the updates will be realtime from publisher to client.
- Native clients for Android and iOS
- (14:30) K Scott asks if Mike’s building native clients. Mike says the iOS client is still in development and the Android app is native. K Scott says he’s wanted to do some Android dev but it’s always seemed like the most difficult platform. Mike says that it’s gotten easier lately due to the new application services and gives an example of the Google Wear Services. Jon asks for some more info on the Google Wear integration and Mike explains how any media framework application automatically gets some support, and they’ve extended it to create a phone application to allow episode browsing on the watch.
- (17:15) K Scott says he was surprised by Mike’s blog post about the demand for Chromecast support for audio applications and asks about the work required to build that support. Mike explains the API integration and says that the hardest part was complying with the look and feel guidelines.
- Advanced podcast support with Podlove
- (20:02) Jon asks if there are things that podcasts can add to enable podcast applications to give a better experience. Mike talks about emerging standards like Podlove which adds support for chapters, time based links, attributions and related feeds. Jon says he’s been including timestamps in the show notes for a while so that seems pretty easy to implement. Mike talks about how TimeJump and Podlove could allow for deep linking into content.
- (22:18) K Scott asks what’s been frustrating in dealing with feeds. Mike talks about the difficulty in feed parsing and the differing standards and implementations. Jon says he’s always just used Feedburner. Mike likes Feedburner and appreciates the built-in support for PubSubHubbub and would like to see Google pay more attention to it.
- Misc: Business plan, mobile web support and Google I/O
- (24:24) K Scott asks if Player FM is Mike’s full time job. Mike says it is. They’re not monetizing it yet, but he’s building out a freemium service with advanced features like unlimited subscriptions and advanced syncing across devices.
- (26:16) Jon asks if Mike has plans for a Windows Phone application. Mike says he’d love to support it eventually, but right now his support for other platforms is via the mobile optimized website and the Player FM feeds.
- (27:06) K Scott asks about Mike’s experience in bringing Player FM to Google I/O. Mike talks about the experience – it was his 4th Google I/O, and he’s been both an attendee and speaker in the past, but this time he was too busy to attend.
- User Experience
- (28:43) K Scott asks how Mike’s psychology degree has helped him in software development. Mike talks about the applications in user interface design and machine learning. Jon asks about Mikes thesis about human computer interaction; Mike talks about user interface design patterns for consistency.
- (32:20) K Scott says he’s happy the Player FM site doesn’t use the ubiquitous cheeseburger menu. Mike talks about some of the UI design features in the web application.
- API Optimization
- (33:19) K Scott asks about optimizations in the API. Mike talks about timestamps in the API responses so the mobile applications can keep aware of which channels have been updated and get the responses from edge servers.
- (36:10) Jon asks about using JSON LD and E-Tags. Mike says he hasn’t needed that since he’s building the clients and they’re doing the same checking.
- (37:39) Jon asks how Cloudflare has worked for Mike. Mike says it’s been great, but there were a few surprises like caching of error responses.
- (38:40) K Scott asks if it’s possible to remove things from the cache. Mike explains some of the options. Jon talks about some of the difficulties in diagnosing content problems when you’ve got multiple levels of caching and Mike agrees that it’d be nice if there were some visibility via HTTP headers.
- Search and Discovery
- (40:48) Jon asks if Player FM has additional markup to light up in search results. Mike says they were one of the early sites to be included in the Google app indexing setup, which supports deep linking in Android applications.
- (42:30) K Scott says he’s looking forward to the recommendation features and Mike describes some of the things they’re including.
- (43:30) Mike talks about Player FM support for full text search using Elastic Search to allow for easier discovery.
- (44:25) Kevin asks if transcripts could be included in the full text search. Mike talks about some of the standards support.
- Wrap Up
- (45:49) K Scott asks what Mike does when he’s not working on Player FM.
- (46:47) K Scott asks Mike what’s coming up for him in the near future. Mike talks about some Player FM features he’s excited about working on like intelligent discovery, collaborative filtering, server-side play tracking, analytics and platform support including an desktop form factor that will work offline. The desktop application is based on an open source project they’re working on that will compile a Chrome application and cross-compile native applications for Windows, Apple and Linux (based on node webkit).
- (48:20) K Scott asks for any last words; Mike says he’s happy for any questions at email@example.com.
This show is brought to you by Runscope – find out more at http://runscope.com/herdingcode
The guys talk to Hadi Hariri about Kotlin, Nitra, and his NDC talk, Developing In A Decade.
Download / Listen: Herding Code 194: Hadi Hariri on Kotlin
- Hello. What is Kotlin?
- (03:07) K. Scott asks about the source code. It’s on Github and it’s under Apache 2 license. He asks who in their right mind these days would design a closed source language *cough* Swift *cough*.
- (03:48) Jon asks about comparisons with the Swift language. Hadi comments and says both Kotlin and Swift are kind of similar to Groovy. Jon asks why not just use Groovy then, and Hadi says that they wanted a statically typed language.
- (05:32) K. Scott asks about the comparisons with Scala and Java. Hadi says that Kotlin is more restrictive than Scala in some cases, which they see as a benefit. They strive for 100% interoperability with Java, since they have 14 years of existing Java source code to work with.
- (11:44) K. Scott asks about .NET support in the roadmap. Hadi says it’s not likely soon. He says there’s a ton of activity on the JVM lately, and it runs everywhere, albeit with the Ask toolbar.
- (13:31) Jon asks about running Java code on Mono and .NET using IKVM. Hadi says he’s tried it on some prototypes and it works, but Scott K complains that it’s really slow.
- (14:33) Scott K. Asks about the use of inference. Hadi says one of the goals of Kotlin is to be very concise, so you very rarely need to declare types.
- (17:43) K Scott asks if there are any libraries that JetBrains has for Kotlin. Hadi describes Kara, a web framework which makes use of strongly-typed HTML and CSS builders. Spec is a specification framework that Hadi’s written. Kotlin is pretty popular for Android development, so there are a lot of Android helpers available.
- (21:31) Jon asks about best places to get started with Kotlin. Hadi says it’s very easy to get started with just the compiler, available from on the Kotlin site. For an IDE-centric experience, use IntelliJ (either the free OSS Community Edition Version or IntelliJ IDEA Ultimate). You can also use the browser-based Kotlin demo without downloading anything.
- (23:06) Jon mentions installing Java JDK via Chocolatey, so as not to get the Ask toolbar. Hadi agrees and says that the Ask toolbar was from back in the Sun days, it’s not an Oracle thing. Jon also asks about the Java browser plugin. There’s a silly discussion about Java applets.
- (26:44) Jon asks about Nitra. Hadi explains the difference between Nitra, Kotlin and MPS. MPS (Meta Programming System) is a language workbench to create new languages or extend existing ones running on the JVM. Kotlin is a separate language, but it’s written in a way that makes it possible to easily create DSL’s. Nitra is an open source tool built by the Nemerle team, who were hired by JetBrains. Nitra is similar to Roslyn – it’s a generic tool that allows you to create a compiler for any language with support for tooling.
- (30:36) Jon asks how Nitra is being used. Hadi says it’s mostly used internally by JetBrains, and it’s still really under development.
- (32:45) Jon asks about the Nitra samples and Visual Studio extensions on GitHub. Hadi says you can start using them already, and that it does include Nemerle so you can start extending the with it now, but it won’t provide tooling for the language you’re building.
- Developing In A Decade
- (33:38) K Scott asks about Hadi’s talk at NDC called Developing in a Decade, looking ahead at technology and trends ten years from now. Hadi says he’s not so much looking at how or what we’ll be doing, but why we’ll be doing it. He says that he sees an overemphasis on how many rounds of VC money a company gets as opposed to what they’re actually doing. He’s interested in things people are doing for social good, and he’s concerned that we’re being destructive without thinking about the effects.
- (39:02) K Scott says that until recently when he called tech support, when he finally got to a person they could help him. Lately he’s been finding that when he reaches a person, they’re powerless to help him because the computers are in control. Hadi talks about how emerging technology like self driving cars will eliminate jobs.
- (41:26) Jon ask Hadi if trends towards automation will have positive effects, such as creating content that wouldn’t have previously been available or giving us more time to produce things we wouldn’t have before. Hadi references Brave New World and Amusing Ourselves To Death, and says that the huge explosion of content has a negative effect. Scott K and Hadi talk about the numbing effect of news as entertainment.
- Parting Shot
- (48:25) Hadi says "I told you so" about the coming unification of Web API and MVC controllers.
This show is brought to you by Runscope – find out more at http://runscope.com/herdingcode
At Techorama 2014 (Belgium), Jon corners Mark Rendle for a few minutes to talk about his new startup, Zudio, "the Azure Cloud storage toolkit," his keynote on the History of Programming, and other minutia.
Download / Listen: Herding Code 193: Mark Rendle on Zudio, developing with Angular and Typescript, The History of Programming, and Simple.Data
- History of Programming
- (00:54) Jon asks Mark what the talk was about, and some of his personal favorite periods.
- (01:53) Jon remarks that some of the joke terrible languages weren’t much worse than the unintentionally terrible languages. Mark mentions Intercal, brainf*** and Malbolge as joke programming languages and IBM Cobol as the most unintentionally hilarious programming language.
- Zudio: The Azure Cloud Storage Toolkit
- (02:55) Mark talks about how Zudio got started and where it’s at. Zudio is a web based tool for managing Azure storage. It’s great for a lot of users, especially PHP / Node / Java developers and in the enterprise. It’s built with AngularJS and Typescript.
- (04:37) Jon said he assumed it was just a simple table grid, but there are seem to be a lot more advanced features. Mark talks about the new enterprise model, which lets you control your user list through Azure Active Directory (which can be synchronized to on premises Active Directory), and you can assign different access rights to users and groups. There’s also auditing and logging to track usage.
- (05:29) Jon asks if he’s specifically focused on storage. Mark talks about upcoming support for SQL databases, including Azure SQL, SQL VM’s, ClearDB running MySQL, Oracle VM’s, Postgres via VM, etc. that will show run queries and show results in a grid, list tables and views, etc. Jon compares it to phpMyAdmin, but Mark says it’s for any database and deployed in the same datacenters, without you needing to spin up a web server. His stretch goal is to handle data migrations between different database systems.
- Angular and Typescript
- (07:19) Jon says that Mark’s been a fan of Angular and Typescript for a while and asks why he likes the combination so much. Mark says it feels like the data binding framework Microsoft’s been trying to build since VB3.
- (10:24) Mark says that unlike most frameworks he’s worked with, he’s gotten to the end of a project using Angular and doesn’t want to throw it out, so that’s saying something.
- Simple.Web and Simple.Data
- (11:33) Jon asks Mark what’s going on with Simple.Web (a simple .NET web framework with attribute routing and dependency injection). Mark says that everything that had driven him to create Simple.Web has been added into ASP.NET vNext, so Simple.Web is pretty much done.
- (14:50) Simple.Data is Mark’s simple data access layer that leverages dynamic types and can work without any code changes against a lot of different databases.
- (15:52) Jon asks why someone would use Simple.Data instead of Entity Framework. Mark explains how Simple.Data works really well in lightweight web frameworks; it’s so simple you can code to it without IntelliSense.
- (16:47) Mark is focused on updates to Simple.Data for use in Zudio, and will we working on more metadata, performance, and async support. He’s looking at moving to async only and is interested in listener input on that.
- Wrap up
- (18:13) Mark likes all the new stuff and thinks it’s a good time to be a programmer.
This show is brought to you by Runscope – find out more at http://runscope.com/herdingcode
The guys talk to Jackson Harper about CodeReview, his iPad application for reviewing GitHub pull requests. As Jackson describes the episode on Twitter: "…hear me talk about:
@johnsheehan, @codereviewapp, and my one weird trick for writing better code."
Download / Listen: Herding Code 192: Jackson Harper on the CodeReview iOS app
- Hello. What is CodeReview?
- (00:18) Kevin introduces Jackson and asks about CodeReview. Jackson talks about how he missed
- (01:25) Kevin asks about some of the specific features in CodeReview.
- (02:05) Jon asks what the CodeReview app adds to the mobile web experience on GitHub. One of the big features is that CodeReview allows for completely working completely disconnected.
- Nerdy Implementation Details
- (04:10) Kevin asks if Jackson’s working against the GitHub API’s. Jackson says he debated working using Git directly, but so far he’s been using the GitHub API. Internally the code is abstracted so in theory it could work against other source code hosts like CodePlex. There’s a brief discussion of Google Glass
- (05:45) Jon asks about Jackson’s development stack. Jackson says he’s working directly in Objective-C and some C as well for the Markdown parser. There’s some discussion of the joy of writing parsers in C. Jackson talks about how some old formats like diff are so much simpler to parse than even newer formats like XML and JSON.
- (08:15) Jon asks why Jackson didn’t use Mono for this application. Jackson says he’s writing Objective-C for his day job, so it’s good for him to write as much Objective-C as possible. Kevin said it seemed like working with Mono would require learning Objective-C to read the documentation. Jackson agrees, but says that learning the iOS APIs using Mono made the transition a lot easier for him.
- (10:46) Jon asks about the BetterFetch feature. Jackson talks about he’d originally modeled the application more like a Twitter stream, so he’d been using the stream API. Over time, it became obvious that an e-mail client was a better application model, so he’s moved off the steam API.
- Business Model and Pricing
- (12:47) Jon asks about the business model and pricing. Jackson said he and JB originally thought that they’d use a freemium model, but they figured out that it really was more applicable for business users who can’t as easily do in-app purchasing. He’s switched to a flat rate to allow for group purchases and generally work better for business scenarios. Kevin says $20 is pretty steep for an app, but Jon says it says it seems completely reasonable for the right application with one of his favorite Android applications which cost $20. Jackson says it’s a perpetual license, iPad apps often sell for a little more, and since it offers a lot of value to businesses he thinks it’s worth it. They’d originally looked at $4.99, but that’s hard to make any money off. Jon says he thinks that the price sensitivity between $4.99 and $19.99 is probably a lot less than between free and 99 cents. Jackson says he wants to sell and support a quality application that’s sustainable.
- Services? Nope, just more repos.
- (18:03) Kevin asks if it’s all run off GitHub or if there are some hosted background services. Jackson says it’s all running off GitHub. He supports storing additional profile data in an optional GitHub repository. Since he knows you’ll have a GitHub application, he can include support for retina quality profile images (and potentially other information) stored in GitHub.
- Design issues
- (20:54) Kevin asks if he’s been working with a designer or doing it himself. Jackson talks about how he’s worked with a few designers and it’s really helped.
- (22:50) Kevin asks if the application’s design reflects GitHub’s design. Jackson says it’s similar, but explains some important differences between the application and the website.
- (24:27) Jon asks about the full screen experience. Jackson explains how it both frees up screen real estate and allows you to focus.
- Code Reviews and Separating the Creative and Editorial Process
- (25:24) Twitter question from Elijah Manor: "Do you use the CodeReview app to review code for the app itself?" Jackson says yes and explains how a bit inspiration for the application was Stephen King’s writing workflow: bang out a bunch of pages in the morning, edit in the evening. Separating the creation and refining steps allow for a lot more productivity. Jon’s very interested and asks Jackson for tips on how to do that. Jackson talks about setting small goals and working in a coffeeshop without bringing his power adapter, so he’s constrained on time and internet use. K. Scott says that the iPad form factor probably helps for this, and Jackson agrees – he sees it as really good for focus.
- (30:41) Jon asks if there are other features he could add by gathering intelligence about my codebase and workflow. Jackson mentions some ideas like hotspots and detecting patch impact. He’s been watching GitHub’s career page hoping to see that they’ll be hiring data scientists to start providing this kind of information. Jon agrees that it’d be great for GitHub to start investing in data science. Jackson says that you could get a pretty good start on patch impact just by manually flagging a few files as important. Kevin says this would have been useful in the case of OpenSSL.
- Code Reviews and Git Workflows
- (34:29) Jon asks about workflow support for larger teams and team hierarchy. Jackson talks about some of the different Git workflow methodologies. He says he might eventually add support for code review tools like Gerrit, although he feels that some of these tools give code review a bad name because they force you to look for minutia as opposed to the big picture.
- When Does it Ship
- (37:56) Jon asks how close he is to shipping. Jackson talks about the beta and some of the challenges of running a beta. [Note: the application is now up on the app store]
- Metrics, Tracking and API Profiling
- (37:35) Jon asks if he’s tracking metrics or tracking. Jackson says he’s gathering crash reports and doing some very basic analytics using localytics because he doesn’t want users to be concerned. Jon says he likes applications give checkboxes to allow for extended tracking. Jackson talks about how he’s using Runscope and would like to allow users to optionally turn Runscope on. Jackson and Jon rave about Runscope; Jackson talks about how a few hours of API profiling helped him significantly improve the application performance. Jon talks about how we don’t think about server interactions, and there’s all kinds of crazy, scary things going on behind the scenes. Jackson tells a horror story about how the Mono site used to return the logo image when you tried to download, and they didn’t find it out until they looked at the server logs. Jon talks about a case where someone requesting the Herding Code RSS feed several times a second.
- What’s Next?
- (48:39) Jon asks what’s next for the app. Jackson talks about the difficulty in cutting off the features and shipping a version.
- (49:29) Kevin asks if he’s got big vision for more than code review. Jackson says he just wants to ship it and will probably start looking at other features eventually. Kevin talks about a polititian who’s put all of his information on GitHub. Jackson says he’s worked with a lawyer in setting up the company and wished they he could work in Markdown. Jon talks about how it would be nice if Markdown had review and change tracking that were similar to Word’s. Jon says that the recent hosted Sharepoint releases are getting close. Kevin, Jackson and Jon talk about how foreign the idea of versioning and change tracking is to most professions.
- Random questions
- (55:35) "Who is the best canadian you know" (Wayne Gretzky)
- (55:55) "What type of dog is your favorite" Labrador
- (55:57) "When will you stop lying about your tweets" There’s a short discussion about deleting tweets and Jackson’s feature request for Tweet focus testing. Jackson talks about a time when Twitter asked users to stop deleting tweets for performance reaons
- (59:20) The app is now live on the app store! You can find out about it at CodeReview.io.
- (1:00:32) Jon asks for some promo codes, Jackson gives away ten free promo codes (below)!
Promo Codes for show listeners (please just take one, leave a comment when they’re all gone):
The guys (joined by guest host Rob Conery) talk to Derick Bailey about his new podcast audio hosting venture, SignalLeaf.
Download / Listen: Herding Code 191: Derick Bailey on SignalLeaf and Getting Started Podcasting
- What is SignalLeaf?
- (00:18) Kevin introduces the show and warns listeners that Rob Conery is present.
- (01:00) Kevin asks Derick what SignalLeaf is. Derick explains that SignalLeaf is a podcast audio hosting service. He explains how his service compares to big players like Libsyn.
- (02:05) There’s a discussion of Libsyn. Jon confesses that Herding Code still runs off WordPress on an "unlimited hosting" account.
- Bandwidth costs
- (02:52) Jon asks Derick if the main cost is bandwidth. Derick explains that SignalLeaf runs on Heroku, but all the storage goes directly to Amazon S3 storage. He agrees that bandwidth is the main cost, and is planning to just make sure the overall subscribers balance out some of the more expensive bandwidth costs.
- (04:52) Jon asks Derick what else he provides outside of audio hosting. Derick says he provides audio hosting, an RSS feed and stats, but he limits it at that. He also provides a blog with a lot of good information. The goal isn’t a big all-in-one service, just keeping it simple for people who want to get started.
- (06:31) Rob gives the example of the rapid takeoff of This Developer’s Life and asks how Derick’s planning to handle pricing for unpredictable bandwidth. Derick says the model’s focused on unlimited uploads, but limited in how many releases a podcaster makes in a month. He’s relying on the law of average to pay for the popular podcasts.
- (09:18) Rob talks about the huge streaming bills he was getting from Amazon for TekPub, which he almost eliminated by switching to Vimeo. He asks Derick if he’s looked into services like that. Derick says the backend is abstracted so he can move to other services if needed.
- What does SignalLeaf run on? (Part 1)
- (11:10) Jon asks about what SignalLeaf runs on. Derick mentions MongoDb (running on MongoLab), Keen.io for analytics and CloudAMQP.com for RabbitMQ.
- What services does SignalLeaf provide?
- (13:25) Kevin asks more about the services SignalLeaf offers. Derick mentions storage, bandwidth, storage and analytics. Something he offers beyond what many other similar services provide is – if you use his RSS feed and embedable audio player – he can tell you where your listeners are coming from.
- (14:50) Derick mentions his blog post showing that about 50% of listeners don’t listen via RSS. Jon said he’s seen the same thing with the Herding Code site.
- Stats and advertising services
- (17:25) Jon says advertisers are always asking for stats, and the kind of stats that advertisers want are hard to find. Derick mentions a service (blubrry) that inserts audio ads, but doesn’t think that sounds like a good idea. He mentions a business podcast running on a free service which had some off-color ads included as an example.
- Getting started in podcasting: What equipment and software do you need?
- (20:40) Rob asks how a developer should get started with creating a podcast. Derick says just hit record and get started. Don’t buy equipment, just record something and upload it and get started. He talks about professional podcasters who put artificial barriers up by focusing on radio quality recording; he disagrees.
- (23:56) Jon mentions Derick’s recent post on getting started. He agrees with Derick and says don’t start by buying equipment, get started and buy equipment as you need it.
- (26:11) Jon says he doesn’t use his high end condenser microphone because it picks up lots of noise and sounds strange compared to guests and other hosts. Rob asks Derick what people getting started should buy to start with. Derick recommends starting with a $26 Logitech headset, then looking at a $50 Audio Technica ATR 2100, a $90 Blue Yeti, $220 Rode podcaster mic etc.
- (30:15) Rob asks about recording software. Derick mentions Garageband, Skype Call Recorder and Audacity. Jon uses a free Skype call recorder from scribie.com, Audacity and Reaper.fm. Jon and Derick both love the noise removal feature in Audacity.
- (33:26) Jon says another thing to figure out at the beginning is how much you want to edit. Jon tries to focus on removing ums and repeated words and things, but leave it sounding natural. Both Jon and Derick say that Rob’s the easiest guest to edit.
- (35:40) Jon asks K. Scott what he uses for recording. He uses Audacity and Camtasia. Jon tells a story about how how he spliced in audio from a previous call when one of the hosts couldn’t make a show. It didn’t make sense, but no one seemed to notice.
- (36:50) K. Scott asks what kind of formats don’t work on a podcast. Derick says that visual features and visual cues obviously don’t translate.
- What does SignalLeaf run on? (Part 2)
- (38:21) Rob asks everyone to guess about the technology Derick’s running on. Turns out it’s all Node.js. Derick talks about how he got started with Node.js. Jon asks about what other libraries he’s using. Derick mentions Express, S3 restful API’s for upload and host, raygun.io for exceptions, keen.io for analytics, stripe.com for billing, MongoDb for data, Mandrill App for SMTP. Derick talks about how little it takes to build up a service now – he’s able to stitch a lot of services together to build what he needs. (45:30) K. Scott asks what text editor he uses. Derick’s a big VIM fan, having started with a Visual Studio VIM extension a while ago.
- (50:07) K. Scott asks whether Derick uses Grunt or Gulp. Derick says he’s thought about looking at Gulp, but Grunt works for him, although he doesn’t like .
- Discussion about managing small, application specific Node modules
- (50:55) Derick says he doesn’t like the way NPM wants you to have a separate git repository for each module – he wants to have all of his modules in one repo. He works around that by using different repositories for development and deployment. Kevin says that his company uses softlinks to work around that, but Derick’s not happy with that. Rob thinks you can do file references, but Derick and Kevin disagrees. Jon asks if submodules would work. Rob and Derick discuss cases where it does and doesn’t make sense to use different repos for different small modules which are specific to a project. Rob talks about using grunt to run an npm install command, or npm init or start scripts (set in package.json), or npm init.
- (1:01:55) Kevin asks Derick if there’s anything else he wants to mention. Derick starts to mention WatchMeCode.com but the calls keep dropping and the show spontaneously combusts.