• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)


Date: Thursday, 25 Jul 2013 05:12

This article is heavily styled and is best viewed at PeepCode!

by Geoffrey Grosenbach

Over the last several years, companies have approached us with acquisition and investment offers.

This isn’t a surprise since the online learning industry has been booming. But I wanted to make sure that any deal would maintain what we’ve built at PeepCode over the last 7 years. If we were going to accept an offer, it had to come from the right kind of company.

Today I’m happy to announce that we’ve found that company. PeepCode has been acquired by Pluralsight.

Pluralsight has been teaching developers since 2004 and has been teaching online since 2008. Their goal is to produce high quality, relevant content in a timely manner — exactly what we’ve been doing at PeepCode since 2006. They primarily teach professional, working developers. And according to their numbers, they are doing it well: they publish dozens of titles every month to over 300,000 subscribers.

The most frequent comment I’ve received from PeepCode customers has been “We love PeepCode! Make more videos! Cover more topics!” Now we can. My new job at Pluralsight will be to build an ongoing Open Source tutorial library that spans the width and breadth of Open Source: not only Ruby and JavaScript, but also Python, PHP, Clojure, Elixir, Scala, and more. The best of PeepCode will eventually move to Pluralsight, including more Play by Play sessions with a greater range of developers and designers.

What does this mean for you? We’re putting together an integration plan that we plan to complete within the next three months. In the meantime, we’ll keep operating PeepCode.com as normal and will be publishing new material to the site and our iOS app (including Play by Play with Katrina Owen within the next week).

And if you want to teach with us, let’s talk. Pluralsight authors earn an average of $40,000 per year. The top grossing author is on pace to earn $1 million in royalties this year alone. There are huge opportunities to teach Rails 4, Node.js, NoSQL, Django, and more.

Pluralsight’s support gives a huge boost to Open Source developers and Open Source software. I’m excited for what we’ll build!

Geoffrey Grosenbach
geoffrey@pluralsight.com
July 24, 2012

Pluralsight individual and business plans are available now and will include the combined libraries of Pluralsight and PeepCode.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

by Geoffrey Grosenbach and Paula Lavalle

A new version of the PeepCode iOS app is free on the App Store! It fixes some bugs and adds a new useful feature.

Fast Playback

The 1.5x button plays downloaded videos much faster.

The 1.5x button plays downloaded videos much faster.

We’ve designed PeepCode videos to be consumed however you want to. Watch straight through to become familiar with a framework such as Ember.js (whether or not you choose to build anything with it). Or go step by step to interactively type along with the code in your text editor. Or relax after work watching Refactoring with Ben Orenstein on your TV.

And now there’s a new way: at 1.5x speed. Download a video in the app and you’ll see an extra button in the playback controls when you play a video you’ve downloaded.

We’ve already benefited from this on a recent plane flights to La Conf in Paris. We watched the 40 minute long Gallery CSS in about 25 minutes. Even less for Troubleshooting. Two hour Play by Play videos can be viewed in under an hour and a half.

Design & Implementation

Custom 1.5x button.

Custom 1.5x button.

Fast playback isn’t built into the iOS movie player, so we had to build most of this from scratch. Our iOS developer built a new playback control with a spot for the 1.5x button. Our designer created a custom button that fits the color and style of the native buttons.

Should Apple implement fast playback in the future, we can revert to the native playback controls by changing a single line of code.

Someone already pointed out that this doesn’t work for streaming locally or to AppleTV. Would that even be possible? Our minds raced. We could re-encode all videos on the server at a faster speed and stream the faster version to AppleTV. Possible? Yes. Tell us if you would find this useful in a future update of the app.

Get the app on the App Store. Upgrade to PeepCode Unlimited for full-length download and streaming!

Did you know…if you’ve ever had a PeepCode Unlimited subscription, you can renew now for only $109! Or tell your employer to contact us for a business subscription.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

Written by Geoffrey Grosenbach · Design by Paula Lavalle

The only thing more difficult than learning something new is teaching it.

At PeepCode, we put a lot of time into creating great explanations of difficult concepts. We won’t publish a video until we’re confident that it explains the topic better than anything else out there. And feedback from people who have viewed our videos on Ember.js, Ruby on Rails, JavaScript and other topics show that we’re doing just that.

 

 

Summary

Here’s some of what we’ve learned about explaining technical topics to developers.

  • Teach one thing at a time
  • Tell a story
  • Use appropriate terminology
  • Know your audience

The Goal

The goal of any tutorial is to get back into the mind of someone who doesn’t understand the topic. If an explanation only makes sense to people who already know what you know, then it’s not a very good explanation.

But that insight alone doesn’t tell you how to explain well. Instead, it might help to think about how developers go wrong when trying to explain a concept.

  • They try to teach too many things at once. This overwhelms the student.
  • They are disorganized. Teaching things out of order makes the student do too much work to sort it out in their mind.
  • They use the wrong words. Throwing an unknown term into an explanation can intimidate a student or even cause fear.
  • They don’t know who they are speaking to. I don’t know of any single explanation that works for all people at all levels of learning. When developers are unclear about their audience, they risk delivering ideas that will confuse everyone listening.

Here are four solutions to these problems.

Teach one thing at a time

This is the biggest problem I see, and it’s the first strategy you should use to improve your explanations.

 

 

Decide what you’re trying to teach, and only talk about that. You’ll have to intentionally block out the 10 other things you want to communicate. If a concept is important enough, dedicate a separate chapter, slide, or day to it. Then focus on the one thing you’re trying to teach right now.

This is extremely difficult for developers. We love details. We love to debate some tiny nuance of a program before it even runs. We like discovering edge cases that no one else has thought about.

And we’re afraid. We’re afraid that when we conclude a presentation, one person in the audience will be able to say “Hah! You forgot to mention X!” Or “You were wrong on this one point!”

To teach well, you need to get over these fears. You need to allow yourself to say something that’s 99% true, even if you know someone will correct you for the 1%. Because mentioning that 1% in your explanation will probably hinder you from sticking to teaching just one thing at a time.

To teach well, you need to abandon your insurance policy of saying “We’ll cover this other thing later.” That disclaimer is only there to comfort you, not to help the student. Teach the one thing you’re trying to teach now, then teach one other thing later when you’ve finished teaching the one thing you’re teaching now.

In fact, leaving out an important concept or saying something that’s only 99% true can be used to your advantage. It can help you tell a story.

Tell a story with problems and solutions

Stories are great because they hold our attention. The story could go anywhere, but we also have a hunch about what will happen next. That anticipation keeps our interest: “Will it turn out like I think it will, or will something unexpected happen?”

Malcolm Gladwell is a great storyteller. Many of his stories use problems as a way to hold attention and lead to a solution (or continue the cycle with another problem and another solution).

 

 

A person figured this thing out. But then they discovered they were partly wrong. And it gave them a new insight into how it really worked. So they applied that knowledge to something else. And then…

When explaining a technical concept, start with a partial explanation that’s easy to understand. In order to make it understandable, you might have to leave out some details. But filling in those details now becomes the next part of your story.

For example:

Solution: Fixtures are Rails’ built-in way for feeding data to your tests. They are a concise way to describe all the data your application needs.

Problem: But fixtures become difficult to maintain when you have many different pieces of data.

Solution: It turns out they aren’t the only way. There are also factories. Here’s how factories work…

Problem: But there’s a problem with factories…

So teach one concept at a time. If you have to leave out a glaring edge case or alternate option, use it to organize your thoughts into problems and solutions that lead from one to the other.

When you’re telling a story, you need to use words. But be careful what words you use…

Beware of Terminology

In every hobby, field of study, or domain, a set of words emerges.

Mountain bikers want to grin while flowing through chunder. Skateboarders are stoked about gnar. Philosophers try not to equivocate about their ideology. Agile developers want to be clean while they keep their objects dry.

These words—big and small—are shortcuts. They make it easy for experts to discuss advanced topics after they already understand the basics.

 

 

If you are teaching experts about advanced topics, then you should use these shortcut words.But if you are teaching people who are not experts, then using domain-specific language will confuse them.

For any term, one’s relationship to the word falls under one of these categories:

  • I have never heard it before, and have no idea what it means.
  • I have heard it a few times but don’t understand it.
  • I have a basic understanding of the word.
  • I have thorough understanding. It’s part of my vocabulary. I can use it to explain other concepts.

Part of your job as a teacher is to help students add new words to their vocabulary. Finding their place in the list above will help you know which words to teach, and which ones to use.

Know your audience

 

 

Finally, understand your audience. I’m mentioning it last, but it should happen first in your preparations.

Are you teaching beginners or experts? Backend programmers or front-end? People with a computer science degree or the self-taught?

This determines what terms you can use. Your professional audience will be frustrated if you spend large amounts of time explaining things they already know. Your beginner audience will be confused if you assume they are fluent in concepts they have never heard about.

This is the first part of your preparations for teaching, but is also the most uncertain. The people who show up for your presentation or consume your material online might not be the audience you prepared it for.

Conclusion

There is a massive need for great explanations on all kinds of topics. Without good explanations, many open source projects will fail. It’s pretty simple: if people don’t know to use your software, they won’t.

So teach one thing at a time that flows from one idea to another with the appropriate words for the intended audience.

And if you think you want to take a crack at explaining a technical topic, contact us. We’re always looking to pay skilled teachers to make videos for us!

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

Written by Geoffrey Grosenbach · Design by Paula Lavalle

Live Designing with Neven Mrgan in Dublin

Live Designing with Neven Mrgan in Dublin

Writing code in front of a live audience can either be the most entertaining and educational kind of presentation, or the most boring and cringeworthy.

In the past few months we’ve been part of two live code and design performances: Úll in Dublin with Neven Mrgan and La Conf in Paris with Katrina Owen. Here are a few things we’ve learned.

Who: A Coder and a Commentator

Live coding alone is really difficult. When most people think about live coding, they remember the minutes of awkward silence when the performer is lost and has to find a way back through the code while the audience waits. The longer it goes on, the more pressure is felt by the performer and the audience feels more pity for the poor fool standing silently in front of a couple hundred people.

Which is a shame since that kind of live problem solving can be the most useful to learn from. But you can’t do it alone.

The solution is to learn from sports broadcasters. Most sporting broadcasts feature both a play by play announcer who describes the action on the field and a second color commentator who explains or opines at a higher level. Wikipedia describes this person’s role as providing “analysis and background information, such as strategy and occasionally anecdotes or light humor.”

The commentator’s job is even more difficult than the coder’s. The commentator must keep the audience entertained while supporting the coder’s attempts to figure out the problem at hand. This will probably involve a few non-deprecating jokes together with insights on programming or thoughts about the code as it is being written. This isn’t pair programming, but the commentator can suggest improvements to the code or help figure out problems, too.

Live Designing with Neven Mrgan in Dublin

Live Designing with Neven Mrgan in Dublin

In Dublin, I was the color commentator, but Neven would have been great in that role, too. He spends his weekends acting in improv groups and has both a quick sense of humor and thought-provoking insights on the design process.

People who have hosted podcasts or done other live interviews would be great for this role. The thing to remember is that a live coding session’s primary purpose is not to produce usable code. It’s to entertain and educate the audience. So pick a coder and a commentator who are entertaining to listen to.

But even when you have a talented pair in front of the audience, you need something to work on.

What: Refactoring

When we edit a Play by Play, we usually cut the initial 10 or 15 minutes where the coder is setting up the basic files for the project. But if you’re writing code in front of a live audience, you can’t fast-forward.

You have two options:

  1. Prepare the code project beforehand. Give yourself a starter kit where you’ve already setup a database or stylesheets or other boilerplate.
  2. Or, refactor existing code.

I think refactoring is a great way to go, especially if this is your first time writing code in front of an audience. Refactoring is both fun to do and fun for the audience to watch. Both you and the audience will be able to look at and think about the same code. If you’re writing code from scratch, your thoughts are opaque to the audience and they will have to wait for you to type it out before they can think about it. In that case, you may as well just show a slide with the completed code.

If you’re refactoring existing code, quick-thinking members of the audience can keep themselves busy by reading and thinking about other parts of the code that you’re not working on.

If you’re using Ruby, it will be tempting to pick a Rails project to refactor. Don’t! A 45 minute lecture always seems too long, but an hour of live coding goes by extremely quickly. A Rails test suite that takes a few seconds to boot and 5-10 seconds to run is far too slow for a live session (even with separate app-forking tools like Zeus).

In contrast, the full test suite for a self-contained Ruby library can run in under a second, which is perfect for a live coding performance.

This still leaves the question of what code you should refactor. I prefer:

  • A self-contained library
  • with few dependencies
  • and a good test suite
  • that is 100-200 lines long.

The entire project can be longer than 200 lines, but pick a file that is 100-200 lines long to start with.

Live Coding with Katrina Owen in Paris, image courtesy of http://lessfilms.com/

Live Coding with Katrina Owen in Paris, image courtesy of http://lessfilms.com/

In Paris, Katrina Owen refactored a single method in an HTTP streaming library that was about 20 lines long and used other methods that added up to about 120 lines. The test suite was in addition to this. When the hour ended, we felt that we had tackled a few interesting ideas but definitely could have kept coding for another 30 minutes. The task didn’t end up being too easy.

If you pick a project with a quick test suite (under a second wall time), you’ll be able to run the tests when it makes sense in the performance rather than running them constantly in the background.

When: Immediately after lunch

More than other types of presentations, live coding can be extremely entertaining and sometimes hilarious.

The time of day when the audience most needs to be entertained and humored is right after lunch. A solo presenter taking the stage after lunch will be greeted by two dozen eyeballs and two hundred eyelids.

In contrast, watching a live coding session keeps the mind alert. The audience will want to guess what happens next, or even keep a list in mind of possible refactorings that the performers should do. “Will their solution match mine?” This involves the audience in the problem solving process rather than putting them in consumption mode (which leads straight to nap mode).

But for an even more lively session…

Bonus: Audience participation

While watching a live code session at a conference, I saw something happening all around the room. People were leaning over to their neighbor and whispering.

They saw the code being written by the performers but weren’t completely happy with the implementation being shown. So they excitedly shared their insights with their neighbor.

Barely 15 minutes before our session, I suggested to Katrina Owen that we encourage the audience to share these insights with everyone. Being a talented improviser, she agreed to this radical last minute change.

The result was disorganized, messy, and exhilarating (just like Open Source software development). Instead of setting up an orderly queue with a single microphone, we encouraged people to shout out their thoughts at any time.

It took a few minutes for someone to take us up on this offer, but then the floodgates opened. People dictated lines of code, shouted out ideas, suggested other methods to refactor, and solved problems for us. It was pair programming times 100!

Best of all, no one fell asleep, even after a delicious lunch.

Conclusion

I’ve learned a lot by watching developers write code and I’d like to see it happen more often at conferences. I’d love to be part of more live code performances, but I would also like to see other people do it. Follow these suggestions and I think you’ll have a hit!

  • Two people: coder and commentator
  • Refactor existing code with a sub-second test suite
  • Schedule the session after lunch
  • Ask for audience participation
Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

words and design Geoffrey Grosenbach
photography Paula Lavalle

The early 2000’s were an exciting time for dynamic programming languages.

Excitement was high for the upcoming Perl 6. It ran on a brand new VM built specifically for dynamic languages and included dozens of experimental syntax sugars such as the hyper operator, which could run a calculation on every element of an array (somewhat like map). I attended the Seattle Perl User Group every month where you couldn’t ignore the anticipation!

It was during these years that I first heard about a weird language that used indentation to define scope (now known as Python). And on January 1, 2001, Dr. Dobb’s journal published an article by Dave Thomas introducing Ruby to the West.

That’s not even counting the other languages I tried out for a few weeks each such as REBOL, RealBasic, and AppleScript.

There must be something special about the start of a decade, because I’m feeling that same kind of excitement and seeing that same kind of experimentation again. At the beginning of May we filmed a 2 hour video with Elixir creator José Valim. Elixir is a language that runs on the Erlang VM but is inspired by the syntax and concepts of many other languages including Ruby, Python, and even Lisp.

It’s not just a transpiler like CoffeeScript; it makes real Erlang .beam bytecode. According to some, parts of Elixir are even more optimized than Erlang itself. It benefits from all the concurrency and deployment options available to Erlang programs. Elixir can call Erlang functions and vice versa.

I don’t pretend to be an Elixir expert (that’s why we worked with José, who is), but I left the session with a lot of enthusiasm for Elixir’s design and features. Here are a few of them.

Smart assert

A programming language like Ruby loses a lot of data when you run it. It quickly loses access to the original source code. If you write a test with Ruby’s basic assert, it can only tell you that the test passed or that it didn’t; it can’t tell you why. Projects like ruby2ruby have tried to bridge this gap but haven’t had support from the core team.

Elixir works directly with your source code to do smart things. Tests rarely need more than the built-in assert, yet meaningful errors can be displayed. Take this Elixir code:

test "makes bacon" do
  assert Bacon.make_bacon() == "avocado"
end

By reading it, we can see that it’s erroneously making bacon but looking for "avocado". We expect that it will fail. If this were a test in Ruby (or any other language), we would see an error such as expected true, got false. Not too helpful.

In Elixir, we see this:

** (ExUnit.ExpectationError)
             expected: "bacon"
  to be equal to (==): "avocado"
at test/bacon_test.exs:14

Elixir knows that == is being used in the assertion, and shows you the values on either side of == when the test fails. Now that’s a useful error!

Multi-block control flow

For years I’ve wanted to be able to write my own control flow structures, such as an each...else that runs an else block if the each is empty (Handlebars templates have this).

The only way to do that in Ruby would be to pass several lambdas to a method, which would be ugly.

In Elixir, the relationship between single line functions and multi-line blocks is well thought out.

These two are equivalent:

# Single line
if(condition, do: a, else: b)

# Multiple lines
if condition do
  a
else
  b
end

In the single line version, if is a function that takes two arguments: the condition and the clauses. The clauses are do and else.

The multi-line version needs no explanation.

But the fact that these two are equivalent means you can write a macro that works just like a built-in. Because that’s how the built-ins are written, too! (source)

Consistent use of do

Developers who love Ruby like the fact that they can override built-in operators and write DSLs that look like built-in Ruby syntax.

But many of Ruby’s syntactical elements are off limits. You can’t write Ruby code that works like a class definition, or an if, or a case...when. Why? class has an end, but no do. There’s no way to write a custom method that takes a block without do.

Elixir is consistent.

Need a module? It’s defmodule...do. Need an if? It also uses do. Same with def.

defmodule MyModule do
  def my_function do
  
  end
end

If you want to write a macro that works like the language does, you can. Because Elixir is implemented with the same tools available for you to use.

Built-in TDD

I find it extremely difficult to learn a new language if I can’t write unit tests. My confidence in writing JavaScript and many other languages went way up once I started using a decent test runner.

With Elixir, it’s built in. Use the mix command to generate a new app and you’re ready to go with a unit test. Run mix test to run the test suite. Done.

It even has conveniences like a test function that takes a quoted descriptive message as the name of the test.

test "extracts m3u8 from index file" do
  m3u8s = Streamers.extract_m3u8 index_file
  assert Enum.first(m3u8s) == Streamers.M3U8[program_id: 1, bandwidth: 110000, path: m3u8_sample]
  assert length(m3u8s) == 5
end

And it can run your tests concurrently with a single async option (docs).

Mind-blowing metaprogramming: upcase

One of the most ingenious techniques that José mentioned didn’t make it into the final cut of our video.

To capitalize a word, Elixir could implement a single upcase function that keeps a list of Unicode letters in memory and figures out how to translate between them.

Instead, it generates a function definition for each letter. They look roughly like this (source):

def upcase("é" <> rest) do
  ["É"] ++ upcase(rest)
end

A few things are going on here. Elixir can match functions on the number, type, and content of its arguments. So it looks for a letter such as é. It knows the upper case version of the letter, then sends the rest of the string to the next letter’s upcase function.

Pretty cool!

Conclusion

Elixir has many of the features that I look for in a programming language. Its authors have stolen useful features from other languages, it focuses on making it easier to write complex applications, and it has a healthy balance between performance and syntax.

Elixir isn’t the only way to write concurrent applications, but it’s definitely one I’ll be experimenting with for a few months. If you want to learn what it’s about, check out our fast-paced two hour video at PeepCode:

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

by Geoffrey Grosenbach

7 Strategies Video

7 Strategies Video

Troubleshooting is a skill that transcends programming languages, frameworks, and even time.

My first few years of professional programming were full of frustration. I would frequently run into problems and have no clue about how to solve them. I treated them as unexpected and unwanted interruptions.

Now I know that encountering and fixing problems is part of the developer’s job description. It’s a rare day that ends without unexpected behavior from code, a deployment, or another library.

But with the right plan, these unexpected events can be resolved quickly. Here’s the order of events we use regularly at PeepCode:

  • Gather data
  • Isolate the fault
  • Form a hypothesis
  • Read the documentation
  • Describe the problem
  • Read the code
  • Try another angle

Free poster!

Download this free poster, print it out, and hang it on your office wall for easy reference. Works on US Letter or A4. Also available in color.

7 Strategies Poster

7 Strategies Poster

Or watch our video for explanations and stories behind these troubleshooting strategies.

Start a PeepCode subscription for $200 or renew for $109! Full access to all videos and our iOS app. Or tell your employer to contact us for a business subscription quote.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

by Geoffrey Grosenbach

Software developers are hard to find. Good ones are even harder.

We’re fortunate to have found one.

Jake Mitchell has degrees in Computer Science and Mathematics. He’s a polyglot programmer with experience in many languages and frameworks. Jake’s the kind of person who you’ll find implementing a TIFF image parser in CoffeeScript that renders to the HTML canvas. For fun.

Jake started working full time at PeepCode about a month ago and has already implemented some useful backend code and started on a new video series for us. If you’ve ever wanted to understand how cryptography works, you’ll want to keep an eye out for it.

You can follow Jake on Twitter here. Subscribe to PeepCode here.

Jamming at the Pioneer Valley Roller Derby in Massachusetts. Photo by Susan Farber

Jamming at the Pioneer Valley Roller Derby in Massachusetts. Photo by Susan Farber

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

words Geoffrey Grosenbach

card design Paula Lavalle

Card front

While waiting in line to buy the original iPad, I gave someone my business card. He said it was an amazing card. In fact, it was the second best business card he had ever seen.

“Only the second best?” I asked. “What did the best one look like?”

“It was a plain looking card,” he said, “but if you sprinkled water on it for a week, it would grow grass in the shape of the company logo.”

I knew it was time to improve our game.

Refresh

Earlier this year we ran out of our old business cards. And PeepCode has grown since three years ago! We now have at least five people who need an awesome card to hand out at tech conferences, at nerd parties, and to random strangers.

We put our best designer on the job. We contracted Evolution Press for advice on paper, ink, foil, paint, and lead type.

Glossy black ink together with silver foil and white lettering make for a combination that can’t really be represented on screen.

Although it doesn’t contain any grass seeds (can you even take those through international customs?), we’re extremely happy with it.

We’ll be at Cascadia JS and other conferences in the next few months. Find us and ask for one!

Card edge

Card foil detail

Card glossy black ink detail

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

The process of writing code is much different from the process of editing code. It’s easy to confuse the two since they both involve mashing buttons on a keyboard while staring at a computer screen.

Vim users know this already. Their editor works in two completely different ways depending on whether they are adding new words to a document or changing existing words.

They also know that there’s more to text editing than moving around with the arrow keys and selecting one letter at a time. But you don’t have to memorize hundreds of commands. I think only these six will handle most of the editing that you’ll do every day.

  • Delete whole words (before and after the cursor)
  • Create a newline and put the cursor there (above or below)
  • Search in a file
  • Switch files
  • Indent code automatically
  • Use completion

1. Delete Whole Words

Steve Yegge writes that it’s much faster to delete an entire word and retype it than it is to navigate to and correct a single letter (see his post on Effective Emacs).

There’s not much else to say here: learn to delete the word before the cursor and the word after the cursor. You’ll immediately find yourself using it constantly throughout the day.

This one is even built in to Mac OS X, so it works in any text editing application (Sublime Text, Pages, TextMate).

Mac OS X

Delete next word:

Delete previous word:

Vim

Delete next word:

Delete previous word:

Emacs (and Terminal)

Delete next word:

Delete previous word:

2. Add Lines

The novice learns to make a newline by moving the cursor to the end of the line and hitting the ENTER key. Or a newline above by moving the cursor up one line, to the end of that line, hitting ENTER, then indent…shouldn’t this be easier?

The Pro can add a newline above or below from any point in the line. You don’t have to move your cursor at all.

Textmate

Newline below

Vim

Newline below

Newline above

Sublime Text

Newline below

Newline above

Thanks to Joaquin Vicente

Search isn’t just for finding words. It’s an efficient way to navigate.

And live search is much faster than using a search dialog. Hit the hotkey and start typing the word. BAM! You’re there. It’s great for navigation instead of using the arrow keys to navigate within a file.

Emacs-style Ctrl-s is also available in TextMate.

Textmate

Live search

Vim

Live search

Hit n to repeat search.

Emacs

Search foward:

Search backward:

Sublime Text

Search forward:

Hit Cmd-i again to repeat search.

Programming happens in files, usually several. TextMate’s fuzzy file search revolutionized my use of my text editor. But it only searches filenames, not directory paths.

This is why I wrote PeepOpen, and I still use it every day.

I think Sublime Text has the best built-in fuzzy file finder of any current text editor. It’s not initially clear that it does this, but it searches on paths as well as filenames. The search score on the left is completely useless to me, but the file and path are a huge improvement over TextMate.

TextMate

Search by filename

Vim

Search open buffers by filename

:b filename

Emacs

Search filenames (using PeepOpen or textmate.el)

Sublime Text

Built-in fuzzy file search

5. Automatic Indentation

Now we’re getting into more advanced features, but still ones that I use constantly.

When using languages without syntactically significant whitespace (e.g. CoffeeScript), I let the editor do the formatting for me. It works 90% of the time, and for the other 10% I’d rather modify my code to work with the built-in formatting than do it manually.

Most developers would refuse to use a text editor without syntax highlighting. To me, auto-indentation is a show stopping feature.

Textmate

For some languages only

Vim

Select a range with V

Emacs

cleanup-buffer

Bound to C-c n

Sublime Text

Only available with language-specific plugins

6. Completion

Let’s admit it: the simple text-based auto-completion in open source text editors doesn’t come close to matching Microsoft Visual Studio from a decade ago.

I hope that a decade from now, I can use a text editor that understands not only the words I’m typing, but their meaning within the application. Without bogging down the rest of the editor or toasting my battery, of course!

In the meantime, I like the way Emacs completes words from all open buffers. TextMate and Sublime Text are limited to only words in the current file, which rarely includes the keywords or methods I’m looking for.

Textmate

For current file only

Vim

Next completion

Previous completion

Emacs

Using dabbrev-expand

Sublime Text

Current file only

SPACE

Conclusion

Learning these basic text manipulations has improved my editing speed. More importantly, I spend less time thinking about my text editor and more time thinking about the content of the text itself.

Try it! I bet you’ll use each of these multiple times in the first day you learn to do them.

Author: "--"
Send by mail Print  Save  Delicious 
New Memes   New window
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

by Geoffrey Grosenbach and Paula Lavalle

Wish granted! Use the following in your presentations, status updates, meme generators, or just for laughs!

Buy the full-length Play by Play or tell your boss to buy you a PeepCode Unlimited subscription for full access to all our videos and our iOS app.

COMPUTERING

Every day we’re computering.

Every day we’re computering.

Solo Computering

“This is how I program.”

“This is how I program.”

High Five!

High five.

High five.

Bingo!

Aww yeah!

Aww yeah!

That’s the word!

“That’s the word!”

“That’s the word!”

Cold Stare

Cold stare.

Cold stare.

Stand back!

Whoa!

Whoa!

Facepalm

So the reason is…

So the reason is…

What?

What? No. No.

What? No. No.

Watch the full-length Play by Play with Aaron Patterson and Corey Haines

Did you know…if you’ve ever had a PeepCode Unlimited subscription, you can renew now for only $109! Or tell your employer to contact us for a business subscription.

Author: "--"
Send by mail Print  Save  Delicious 
Date: Monday, 15 Jul 2013 17:26

This article is heavily styled and is best viewed at PeepCode!

by Geoffrey Grosenbach and Paula Lavalle

From the It Just Makes Sense department

Stream to your Apple TV! We’re watching Play by Play with Corey Haines and Aaron Patterson.

Stream to your Apple TV! We’re watching Play by Play with Corey Haines and Aaron Patterson.

As a bootstrapped company, it’s not always clear what the next step is, but an iOS app for viewing PeepCode videos has been one of the longest standing requests we’ve received. Which makes sense! It’s almost as if these devices were perfectly designed for watching PeepCode videos. The new iPhone 5 is the right dimensions for displaying HD video, which is what all our new videos have been filmed in since the end of last year (and some before that).

So we (finally) took the plunge and built an iOS app. We worked with expert iOS developer (and PeepCode author) Alex Vollmer of Radiant Capsule, and while he did most of the heavy lifting we certainly put in a lot of work and learned a lot along the way.

Solving the Progress Bar Problem

Download progress shows both percentage and remaining MB.

Download progress shows both percentage and remaining MB.

Desiging a good progress bar is famously difficult. Given that our audience is technical and speaks MB and GB, we settled on a great solution that works specifically for the content we’re delivering.

We decided to combine a standard progress bar with a numerical percentage. This works well for any videos under 100MB. But large videos might appear to be stalled if we can only show 100 points of progress. If a video is 500MB, it might take a minute or more to download 1/100th of it (5MB) and show progress.

So we also show you the number of MB remaining. This gives visual feedback that’s useful for videos larger than 100MB. The end result is that for any video you’ll download, progress is frequent and keeps you updated.

Delivering Instant Gratification

The UI shows progress in two steps.

The UI shows progress in two steps.

One of the things we find frustrating about video streaming applications is all the waiting.

Starting an HTTP video stream can involve an API call, requests for 2 metadata files, and another request for a media file…all before you see a single frame of video.

We wanted to improve on that by showing you some progress along the way. So you’ll see an initial spinner when you click the “Play” button on the cover. When the first API call has completed, you’ll be taken to the video player where the video will start to stream.

Splitting progress into two visual steps makes the application feel more responsive than it would if we just sent you directly to the video player where you would have to wait for 5 or 10 seconds. It’s part of the attention we’ve put into the UI of this application to make it enjoyable to use.

Note: Video streams start at low quality while the device figures out what bandwidth is available. If you have a good Internet connection, you’ll see better quality video after a few seconds. We’re working on adding full HD streams to videos, too.

The Value of a Flaky Development Server

It’s not easy to bootstrap a multimedia application that requires client, server, and media.

Due to misbehaving third-party libraries, our first implementation of a video streaming server would sometimes monopolize 100% of the server’s CPU and hang, or never return a response at all. This was bad news for the iOS client application since it couldn’t get the data it needed to start streaming a video.

Or was it? The early flakiness forced Alex to add more error checking code to the iOS client, and better error messages for the user. And it forced us to write the server code to look for timeouts or blank API responses. Overall, it made our code more robust.

Brother Baba Budan, Melbourne

Brother Baba Budan, Melbourne

And yes, we rewrote the server so it doesn’t use 100% CPU anymore. In fact, it’s been smooth sailing since the launch.

Keeping it Simple

We’ve launched version 1.0 with a simple but straightforward feature set: PeepCode Unlimited subscribers can download or stream any video we’ve published in the last two years. We’re starting with only PeepCode Unlimited subscribers so we can fine-tune our streaming infrastructure and determine what mirrors we need around the world for a top notch download and streaming experience. So far everything has been running very well.

Anyone with a PeepCode account of any kind can use the app to stream previews of current videos.

Interesting Features

  • The app will remember the playback time of each video you’ve watched. If you have iCloud, it will sync that across all your devices. So you can watch part of Play by Play with Aaron Patterson and Corey Haines on your iPhone, then resume watching on your iPad at the same time in the video.
  • We’ve done extensive testing, literally all around the world (Seattle, Melbourne, Kauai, San Francisco). We hope to add video streaming mirrors for an even better experience.
  • Stream to your AppleTV with AirPlay. Play by Play looks fantastic on an HDTV.
  • Smart download doesn’t drain your battery if you leave the app. It resumes when you’ve re-launched the app and are back in Wi-Fi range. (Our developer tested this by walking down the street until he was out of range).
  • Download full quality videos or stream up to half resolution. Our new HD videos look amazing on the iPhone 5!
  • We built a custom, self-contained Sinatra server for streaming video. This will make it easier for us to deploy extra streaming or download servers around the world or whenever needed.
  • A series of command line scripts together with remote APIs makes it a breeze to encode video for all the necessary formats and copy it to our servers.

Try it!

We’re proud of this application, our first shipping iOS application. For a 1.0, it covers most of what’s needed for a great mobile experience.

Possibly the best evidence of how useful this application is was how much we started using it in-house! On the bus, at home streamed to an Apple TV, or on a plane. The last three months of rigorous testing and refinement have been a lot of fun.

Try it out with any PeepCode account. Or upgrade to PeepCode Unlimited for full-length streaming!

Did you know…if you’ve ever had a PeepCode Unlimited subscription, you can renew now for only $109! Or tell your employer to contact us for a business subscription.

Watch on the iPad, too!

Watch on the iPad, too!

Author: "--"
Send by mail Print  Save  Delicious 
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader