Merlin42 - Slashdot User

YouTube, HTML5, and Comparing H.264 With Theora 361

Posted by Soulskill on Sunday June 14, 2009 @02:34PM from the quality-vs-bandwidth dept.

David Gerard writes "Google Chrome includes Ogg support for the <video> element. It also includes support for the hideously encumbered H.264 format. Nice as an extra, but ... they're also testing HTML5 YouTube only for H.264 — meaning the largest video provider on the Net will make H.264 the primary codec and relegate the equally good open format Ogg/Theora firmly to the sidelines. Mike Shaver from Mozilla has fairly unambiguously asked Chris DiBona from Google what the heck Google thinks it's doing." DiBona responded with concerns that switching to Theora while maintaining quality would take up an incredible amount of bandwidth for a site like YouTube, though he made clear his support for the continued improvement of the project. Greg Maxwell jumped into the debate by comparing the quality of Ogg/Theora+Vorbis with the current YouTube implementations using H.263+MP3 and H.264+AAC. At the lower bitrate, Theora seems to have the clear edge, while the higher bitrate may slightly favor H.264. He concludes that YouTube's adoption of "an open unencumbered format in addition to or instead of their current offerings would not cause problems on the basis of quality or bitrate."

Comment Your sig is deep (Score 1) 686

by Merlin42 on Tuesday September 09, 2008 @03:58PM (#24937571) Attached to: How Do You Deal With Telemarketers?

Analysis of the DNA of George W. Bush: 100% introns - they expressed nothing useful.

As I understand it those non-expressive genes actually control all the other genes ... they are The Deciders ... thats deep!

Submission + - "Working Effectively with Legacy Code" - A (thefitch.com)

Submitted by

Merlin42

on Thursday September 04, 2008 @06:21PM

Merlin42 writes: "I recently took a Test-Driven-Development (TDD) training course and the teacher recommended that I read "Working Effectively with Legacy Code" by Michael Feathers. First things first, a note about the title. Feathers defines "Legacy Code" a bit different than you may expect, especially if you are not into the XP/Agile/TDD world. I have heard (and used) a number of definition for "legacy code" over the years. Most of these definitions have to do with code that is old, inherited, difficult to maintain, or interfaces with other "legacy" hardware/software. Feathers' definition is "code without tests." For those not into TDD this may seem odd, but in the TDD world, tests are what make code easy to maintain. When good unit tests are in place, then code can be changed at will and the tests will tell automatically you if you broke anything.

Overall this is definitely an interesting read, and useful to anyone who has ever yelled "FSCKing LEGACY code!" It will be most useful to someone who already has some appreciation for TDD and wants to use it to "pay down the technical debt" in a legacy code project. In my opinion adding unit tests (a sort of retroactive TDD) is the best ... err ... most effective approach for getting a legacy code project into a more malleable state.

One caveat is that most of the book is focused on working with object oriented programming languages. There is some coverage of techniques for procedural languages (mainly C), but this is not the main focus of the book. In a way this is unfortunate, since there is a lot of really useful C code out there gathering dust. But in the book he states that "the number of things you can do to introduce unit tests in procedural languages is pretty small." Unfortunately I would have to agree with him on this point.

One of the greatest things about this book is that it is written by someone who has worked with a lot of legacy code, and there are numerous real world anecdotes sprinkled throughout the text that really serve to help drive the points home. The code examples are plentiful, but not verbose. They all look like real code you might find lurking in a dark corner at work, not some fanciful made up snippet.

The high level goal of the book is show you how to write good unit tests for code that wasn't designed with unit tests in mind. The first step for writing unit tests is getting individual classes or functions into a test harness where you can apply known inputs, and check the outputs or behavior. To do this you need to break dependencies in the original code. The bulk of the book is dedicated to looking at different approaches to breaking dependencies.

Much of the book is organized like a FAQ. There are chapter titles like: "I Need to Make a Change. What Methods Should I Test?" and "My Project Is Not Object Oriented. How Do I Make Safe Changes?". This organization makes the book work a bit better as reference than as learning material. After the first few chapters there is very little flow to the book. Each chapter tends to stand as an independent look into a particular problem common in legacy code. As a result, you can read the table of contents and usually skip to a self-contained chapter that will help with the problem at hand.

The final chapter of the book is a listing of all the refactoring techniques used throughout the rest of book. So if you have a particular dependency breaking ,technique in mind you can skip straight to the description of the technique you want to use. This can be quite helpful when you need to perform a refactoring before you can get your code into a test harness. The descriptions are straightforward and provide a little checklist at the end that will help you make sure you didn't miss anything.

In conclusion I would definitely recommend this book to a colleague who is trying to introduce unit tests into code that was not designed with testing in mind. In fact I have already lent the book to several people at work, most of whom have bought their own copy."

Defunct Spy Satellite Falling From Orbit 312

Posted by kdawson on Saturday January 26, 2008 @06:26PM from the cue-the-chicken-little-jokes dept.

dnormant, among other readers, sent us word that a US spy satellite has lost power and propulsion and could hit the Earth in late February or March. Government officials spoke on condition of anonymity because the information is classified as secret. None of the coverage speculates on how big the satellite is, but Wikipedia claims that US spy satellites in the KH-11 class, launched up to the mid-90s, are about the size of the Hubble — which is 13 meters long and weighs over 11,000 kg. "The satellite, which no longer can be controlled, could contain hazardous materials, and it is unknown where on the planet it might come down... A senior government official said that lawmakers and other nations are being kept apprised of the situation."

Slashdot Top Deals