Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Submission Summary: 0 pending, 41 declined, 10 accepted (51 total, 19.61% accepted)

DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Submission + - Testers: Get Out of the Quality Assurance Business (

Anml4ixoye writes: Tester Michael Bolton (yes, that's his real name) has a great article entitled Testers: Get Out of the Quality Assurance Business. From the post: "The quality assurance role in the company, Cem said, lay with the management and the CEO (the principal quality officer in the company), since it was they—and certainly not the testers—who had the authority to make decisions about quality." It's a must read for any tester, developer or manager who works with software projects, and came about as a result of my challenge: "Having a QA department is a sign of incompetency in your Development department. Discuss."

Submission + - Bill Gates helps fund mass circumcision programme (

Cory Foy writes: "From the New Scientist article: "Microsoft founder Bill Gates last week injected $50 million into a programme to circumcise up to 650,000 men in Swaziland and Zambia...Funded for five years through the Bill and Melinda Gates Foundation, the programme is the first to massively scale up provision of circumcision by fully trained medical practitioners.""

Submission + - Swapping Developers to Beat the Recession (

Cory Foy writes: "There are many unique ways to beat the recession — cutting staff, cutting perks, etc. But what about taking one of your most senior developers and sending them — to your competitor? And getting one of their senior people in return? That's exactly what the companies 8th Light and Obtiva out of Chicago did a couple of weeks ago. They were encouraged by Corey Haines, who after getting laid off himself, set out on a pair programming tour around the country for room and board. The whole thing was featured in the Chicago Tribune over the weekend, and is a great way to show how innovation can truly happen."

Submission + - Beginning iPhone Development

Cory Foy writes: "When my wife got an iTouch several months back, the first thing I wanted to do was build some applications for it. Who wouldn't want to play with a device that has accelerometers, position sensors and multi-touch gestures? But being new to the Mac world, I needed something to help guide me along. Beginning iPhone Development aims to be that guide. But does it live up to the challenge of teaching a newbie Mac and iPhone developer?

The first thing you'll need to do is head over to the Apple Developers Site and register for an account. You can then download the iPhone API. Note that while the API download and simulator are free — deploying to a real iPhone or iTouch is not, even if it is your own. To do that you have to apply to the iPhone Developer Program which is $99. For the book, you'll be fine with just the simulator with the exception of any accelerometer application, since the simulator doesn't have that feature.

With that out of the way, I was quite impressed with the book. Although I've done quite a bit of development in the past, I haven't worked with Objective-C before, and was a little concerned if I would be in over my head. If you are in that position, don't fear — the authors do a great job of walking you through, and you'll find yourself working with it in no time.

The first chapters introduce you to the basics of the iPhone and development, starting with the canonical "Hello, World" application. The book walks you through how to get and install Xcode and the iPhone API. It then introduces you to Interface Builder, the partner-in-crime to Xcode. Even in the first chapter, the authors show their attention to detail, explaining common issues you might run into (like trying to Build and Run while your iPhone or iTouch is plugged in to your Mac).

Chapter 3 introduces the Model-View-Controller paradigm, a pattern that is probably one of the most misunderstood patterns in UI development. They give you enough information to be familiar with the terms you'll be using, and they very much mean it when they tell you not to worry if you aren't understanding something — they always loop back around to make sure you understand it.

Chapter 4 was a long chapter for me, but introduces some important concepts around user interaction and controls. By the end, you have an interface which has a variety of controls which interact with each other. As with the other chapters, the authors introduce tips and tricks to make things easier (for example, Option->Cmd->Up Arrow to switch from the header to implementation file in Xcode).

Chapter 5 covers autorotation and basic animations, including linking in the Core Graphics Framework. I especially like how the authors gave three different ways of making your app auto-rotation aware, describing the benefits and drawbacks of each. Chapter 6 follows this up by introducing multi-view interfaces, something very necessary as you get into more complex iPhone development.

Chapters 7-9 describe various methods to presenting information to users, including toolbars, table views, hierarchical navigation and hierarchical lists. However, it isn't all drag-n-drop, the authors get into some good (and sometimes deep) conversations about what you are doing. For example, in Chapter 8, they talk about issues with NSDictionary and how to create deep mutable copies.

Chapters 10-13 are the last of the "fundamentals" — application settings, basic data management, custom drawing using Quartz and Open GL, and taking inputs (including gestures and multi-touch). As someone who spends most of his time as far away from graphics libraries as possible, I was quite impressed with the basics that were introduced and what someone like me could get up and running.

Finally we get into the fun. Chapter 14 introduces Core Location, allowing to figure out where in the world you are. The book goes through a discussion about the various ways to get location information, and drawbacks of each. (Helpful tip: no matter which method, if you are polling every second, you'll drain the battery pretty quickly). For the simulator-only users, this is when things start to become tricky. Chapter 14 does work, though you aren't prompted for access to Core Location.

Chapter 15, however, is useless without an actual phone, even though it's perhaps the most fun. In this chapter, the book goes through the accelerometer and all the interesting things you can do with it. There's even a small discussion on the physics (but just enough!). Both apps you create (Shake and Break and the Marble game) are quite fun for someone just starting out with all of this. It's a shame Apple couldn't figure out a way yet to include the accelerometer in the simulator.

Chapter 16 covers using the iPhone camera and Photo Library. It's short, but it shows the power of the simple interfaces Apple provides. In just 9 pages you'll be capturing images right from the iPhone.

The final two chapters I thought were quite fitting — Localization and Follow-Ups. In the localization chapter, the book covers extracting strings out to resource files and using locale to read them in. Having a day job which ships our software in 12 different languages, I know first-hand how difficult localization can be to get right, so I was glad to see this chapter. The final chapter is just a wrap-up of resources you can reach out to for help and information.

All in all I was very surprised and pleased with the book. I've had the fortune of reading many technical books, and few do a great job of walking someone through the basics without making them feel like a dolt. It felt like every time I was stuck or unsure there was a tip, hint or paragraph which explained what was going on.

The main drawback to me is the fee to deploy apps to your own phone. This wasn't something I ran into doing either J2ME or Windows Mobile apps in the past, and it is a shame that to even work on your own phone you have to pay a fee. However, since the fee does give you the ability to submit apps to the App Store, then I guess it's a consolation. I'd rather Apple lock deployments to one iPhone (or iTouch) for the truly casual people who just want to do interesting things on their own phone.

In summary, I give this book five $1000 Rubys for making a clean, concise, easy-to-read and follow introduction to iPhone development. Great job guys!"

Submission + - Clean Code

Cory Foy writes: "As developers, system admins, and a variety of other roles in IT, we have to deal with code on a daily basis. Sometimes it's just one-off scripts we (hopefully) never have to see again. Sometimes (Ok, most of the time) we stare at something that, for the life of us, we can't understand how it came out of a human mind (or, as the book puts it, has a high WTF/minute count). But there is a time when you find code that is a joy to use, to read and to understand. Clean Code sets out to help developers write that third kind of code through a series of essay-type chapters on a variety of topics. But does it really help?

I had the pleasure of attending Bob Martin (Uncle Bob)'s sessions at several agile software conferences over the past several years. In them, Bob has a unique way of showing us the value of clean code. This book is no different. There is a warning in the introduction that this is going to be hard work — this isn't a "feel good" kind of book, but one where we slog through crappy code to understand how to make it better. The authors also point out that this is their view of what clean code is all about — and fully acknowledge that readers may "violently disagree" with some of the concepts.

The book wastes no time diving in covering "Meaningful Names", "Functions" and "Comments" right in the first several chapters. While I could sum up the chapters by saying, "Use them", "Keep them small" and "Comments don't make up for bad code" it wouldn't do the wisdom in the book justice. For example, in the meaningful names chapter, he talks about making pronounceable and searchable names — staying away from things like "genymdhms" (Generation date, year, month, day, hour, minute and second) and preferring things like MAX_STUDENTS_PER_CLASS.

After touching on formatting rules (including some very interesting graphs on the file and function length distributions in some common open source projects) he dives back into some more controversial topics — "Objects and Data Structures", and "Error Handling". The Objects chapter does a great job of drawing a line in the sand between Objects and Data Structures and why it really is both important, and clearer, to keep your privates in your private classes.

The Error Handling chapter is important because of the application of earlier chapters — the Do One Thing rule. Your functions should do one thing — either handle business logic, or exception handling, but not both. It's the difference between this:

try { s = new Socket(4000); s.OpenSocket(); string data = s.ReadFromSocket(); if(data == "32") data = "42"; printer.print(data); } catch(Exception ex) { if(ex == NetworkInterruptException) { //do something } if(ex == PrinterOnFireException) { //do something } logException(ex); }

And this

try { tryToPrintDataFromSocket(); } catch(Exception ex) { logException(ex); }

We then move on to "Boundaries" and "Unit Tests" — the critical points where we tend to really let code go. If we work hard, usually we can keep our own code clean. It's when we have to begin interacting with other systems that things start to go astray. In these chapters, Bob and James Grenning show us how to keep our code at the boundaries clean — and how to keep our code working, period. The authors are proponents of Test-Driven Development, and the chapter on unit tests is a fresh reminder that those tests are just as much code, and need to be kept just as clean as any other code we write.

We then begin to move at a higher level, starting with "Classes" and "Systems". The classes section should be familiar to most any OO programmer — keep the classes small, with a single responsibility, and low coupling. He also talks about Organizing for Change which is a great section on how to structure classes in a way that keeps them open to change. The Systems section continues along the path with the great reminder to "Separate Constructing a System from Using It". Here they go into Dependency Injection and Aspect-Oriented Programming, which I'll address in a bit.

Moving even higher up the chain, the book then tackles "Emergent Design". The key is to keep the design simple, which according to Kent Beck, means:
  • Runs all the tests
  • Contains no duplication
  • Expresses the intent of the programmer
  • Minimizes the number of classes and methods

With the above list given in order of importance. Really this breaks out to "Runs all the Tests" and "Refactoring" or making the code better. Simple design is perhaps one of the harder things out there, and yet the most important. When you look at systems that highly scale, it's because they are made up of simply designed components which work very well together.

After the Emergent Design chapter there is suddenly a chapter on Concurrency. This was not something I expected to see, but was very glad to. Too many times books about patterns and design don't address problems like scaling and concurrency. But this chapter does a great job of introducing the necessary steps that need to be taken to deal with concurrency — while still keeping your code clean. The book also provides an appendix which goes even deeper into the concurrency topic which I found to be quite good. Both this chapter and the appendix provide some very valuable rules that I personally have used when writing concurrent systems — like "Get your nonthreaded code working first" and "Run with more threads than processors" to flush out problems.

Chapters 14-16 cover the cleaning up of three different sections of code — an argument processor, JUnit and SerialDate, which is part of the org.jfree package. These chapters really hold true to the warning in the introduction that we'd be going through some code. However, the refinements work very well, and I think that each of them show the value of how much cleaning up the code can improve the readability of even code that works well and seems clean.

The last chapter is a "Smells and Heuristics" chapter which I'm finding to be a handy reference guide for code smells I see. When something is bothering me with code I'm reading, I flip to this section first to see if they have it listed. And with things like "Replace Magic Numbers with Named Constants" you can be sure that all of the advice that should have been beaten into your head long ago is still there, and relevant.

All in all I think this is a very valuable book for any developer wanting to improve how they write code. For senior level people, some things may seem trivial, but if you really take the time to look at the structural changes being made and apply them, you will write better code. For functional developers — the authors believe in OO, but there are still valuable nuggets that are applicable outside of that (like "Use Copies of Data" in the concurrency section). And for any developer, the insights are really good, and you'll find yourself writing down little snippets to hang on the wall.

The challenges with the book are first that it is just as they said — hard work. This is not a flip-through-with-your-mind-shut-off type book. If you want the most out of it, you have to be willing to really work at it. The other challenges are that at times it gets way too Java-centric. All of the code examples being in Java is fine, but some of the chapters (most notably the Systems chapter) really go heavy into Java tools and the Java way which, to me, weren't always applicable across languages.

All in all, I'd highly recommend this book to anyone wanting to improve how they write code. You likely will find yourself violently disagreeing with parts, but the total sum more than makes up for it."


Submission + - Microsoft makes bid to buy Yahoo! (

Anml4ixoye writes: "Nothing like waking up to an email from Steve Ballmer saying that Microsoft has made an offer to buy Yahoo!. From the article:

Microsoft made an unsolicited $44.6 billion cash and stock bid for Yahoo Friday, a deal that shakes up the competitive and lucrative market for Internet search. The deal would pay Yahoo shareholders $31 a share, which represents a 62% premium from Thursday's closing price.
Wonder how the Search guys feel about that announcement..."


Submission + - Man Arrested for Cursing in Public Park (

Anml4ixoye writes: "While visiting Sarasota, FL, you could be locked up for breaking the law if you are theft, assault, or any of the other normal offenses. You can also be locked up for "prohibitions against gambling boats, visiting a 'house of ill fame' and 'being in a public place in a state of nudity or in a dress not belonging to such person's sex.'" These so-called "Offenses Against Public Morals" extend to what you can say in a public place. Just ask Christopher Haudt who had charges brought against him for swearing near a minor during a public park's opening."

Submission + - Teamprise releases free version of TFS Client

Cory Foy writes: "Microsoft's open-source site CodePlex has lacked something big since its inception — a way to access the underlying source control system, Team Foundation Server, from a non-Windows machine without buying a license from a third-party company. However, last week Teamprise, a company who makes a Java-based Team Foundation client, announced they were giving away a license to their client for open-source developers using CodePlex. This is great news for people who actually do cross platform .NET development."

Submission + - Review: Pro Java ME MMAPI

Cory Foy writes: "Several months ago Vikram Goyal emailed me letting me know he had a new book coming out from Apress — Pro Java ME MMAPI: Mobile Media API for Java Micro Edition. Having done mobile device development using J2ME, I knew how difficult it can be to do — or explain — some of the tricks in device development. So I wanted to see if this book could raise up to the challenge.

Vikram quickly sent me a copy, which I started to look through. And then we moved. Somehow in the move the book got packed in a box that was marked "Garage Sale items" and promptly shoved into our garage of our new house. While looking for some other things for my trip to Budapest, I stumbled across the box, and the book.

And am I glad I did. I've noticed as of late that the quality of the technical books I've been reading has deteriorated. Misspellings, wrong calculations, grammatical errors — not the thing to inspire confidence in the subject. In addition, the content can be hard to follow, it's hard to grasp where the author is going, etc, etc.

Not this book. I was immediately struck in the first chapter by how clearly written the book is. Yes, you need to have some knowledge of J2ME device development (specifically MIDlets), but Vikram does a great job easing you intothe subject, and providing good, easy to follow examples.

The subjects he is covering — dealing with media on mobile devices (specifically phones) is a particularly tricky subject. The problem? Many device manufacturers implements standards — differently. They claim to support things they don't. They ignore features you would expect. And worse, their emulators, the very thing you develop against, don't always match the phone. In fact, very rarely do they match the phone.

Vikram tackles this by testing his code on several different types of devices, and clearly lists out the dangers of relying on just the spec, or the reference implementation, or the emulator. Heck, I've seen versions of the same phone work differently based on what the provider had done to the phone. Verizon will always be evil to me based on my experiences of porting code that worked great on Nextel to Verizon phones, but that's another story.

Back to the book. The chapters are clearly laid out in an order I think provided a great learning roadmap. In chapter 1, he introduces the Mobile Media API (MMAPI) explaining what exactly it is, how it ties into things like MIDP 2.0 (Hint: MIDP 2.0 contains a subset of MMAPI functionality), and who supports it.

Chapter 2 provides an overview of the basics of the MMAPI. In particular, how to get data from a DataSource to play in a Player. Since the MMAPI is designed to be implemented by device manufacturers, it is a great read to see how an API can remain simple, yet cover a vast array of inputs and outputs. For example, Player instances can read files, streams, web sites, and a variety of other inputs. It can control audio, video, MIDI and tones. All of this using the same underlying API. Pretty good stuff.

Chapter 3 gets us diving into some code. We write a basic multimedia player, and then improve it to add functionality and increase performance by understanding what is involved in caching Players.

Chapter 4 continues on explaining the more about the underlying architecture, specifically the media player lifecycle and events. Since we are dealing with devices that generally have limited resources, the API provide a way to save claiming those resources until as late as possible. In addition, it provides ways to reclaim those resources, and Vikram covers some of those ways in this chapter. He then moves on to discuss the eventing architecture, and how to respond to custom events (he does briefly describe writing your own events — but I can attest that getting anything that low level on a device from US providers is usually pretty difficult).

It wouldn't be a good programming book if we didn't talk about threads at some point, and Vikram touches on it in Chapter 5. Specifically, we're diving into accessing files over the network, and we don't want to block the device while we are doing that. Yes, when you are running a MIDlet, the app thread is the main phone thread, so if it is waiting for network traffic, the phone is unresponsive to the user. So very wise use of threads is necessary. In addition, some security considerations start coming into play, and the book covers what to expect.

Now the fun starts. In Chapter 6, the book discusses Tone Control, the first of 2 entertaining chapters on making your device make noise. The chapter starts off with a very concise explanation of basic music theory to give developers an understanding of what they are going to need to do to generate tones of different pitches. It then moves on to the difference between Mono and Polyphonic notes, and how to create sequences of notes. By the end of the chapter, you too can have your phone playing "Happy Birthday".

Chapter 7 continues on with the party, going into one of my favorite subjects — MIDI. Again, we get a good, concise introduction to the fundamentals of MIDI. We then get to see how to send raw messages to a device that understands MIDI, and how to use MIDI in the MMAPI.

Chapter 8 touches on the other aspect of media — Video. To do this, it first discusses sampled audio, and how to capture and control it. It then goes into capturing video, which many devices may not support, and how to capture snapshots for those devices with cameras. It also covers what to do with the file when you've captured it (for example, save it or display it to the user), and closes with a discussion on streaming media.

I was surprised when I got to chapter 9 because chapter 8 ended by saying what we were going to cover in the final chapter, and I hadn't realized that I had read that much already! Chapter 9 is a great way to end the book — Vikram shows us how to implement our own mobile blogging website, complete with implementing uploads for Text, Audio and Video (if our devices support it). He even provides screen shots and full code, walking through it step by step to help us understand what is going on.

All in all I very much enjoyed the book. If you have a phone capable or supporting J2ME, this is definitely worth a read. The writing is very clear, and entertaining. If there is a downside, it the poor integration of J2ME in a lot of providers devices, and the inconsistencies in the implementations. But thankfully Vikram guides us through all that so we can quickly be up and running singing along to our favorite dance hit with the words on our phone, mobile blogging the whole thing."

Submission + - Open formats save the day

Amnl4ixoye writes: "This evening, I had the unfortunate experience of shift-deleting my entire Inbox for one of my accounts in Thunderbird. However, thanks in part to their openness of formats and standards, I was able to save the day by making some simple changes. Thank you open and clear formats!"

Submission + - Review: Practices of an Agile Developer

Anml4ixoye writes: "Whatever you do, don't touch that module of code. The guy who wrote it is no longer here, and no one knows how it works."1 In Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt put that quote as an example of something we are all afraid to hear, but probably have in our careers. They then go on to list a collection of practices which can keep you from hearing, or worse, saying that phrase. How do they do? Read the review below.

I was excited when I received this book. Having gotten the chance to meet and talk with both Venkat and Andy, I knew they were passionate about getting developers to understand how to deliver value to the customers. Both are proponents of Agile development in one form or another (XP, Scrum, Crystal, etc). But rather than try to sell you on one of the methodologies, they laid out seven goals:
  • Beginning Agility
  • Feeding Agility
  • Delivering What Users Want
  • Agile Feedback
  • Agile Coding
  • Agile Debugging
  • Agile Collaboration

In the first, Beginning Agility, they lay out the basics of becoming an Agile developer. Things like Working for Outcome (in other words, don't blame people for bugs, find out how to fix them and fix the process that caused them) and Criticize Ideas, Not People. Or avoiding the pitfalls of making quick hacks without trying to understand why the hack was necessary (Quick Fixes Become Quicksand). They finish up the chapter with a key word I personally feel is absolutely necessary in software development — courage. They put this in the context of Damn the Torpedoes, Go Ahead. In other words, if the code you are working on is stinky, and you'd like to throw it away, don't be afraid to bring that up. Or if code you are in the middle of building suddenly becomes the wrong direction, stand up and explain that (being sure that in both circumstances you have alternatives for getting it on the right track).

The second chapter, Feeding Agility, discusses ways to keep the flow going while being Agile. Things like Keeping Up With Change remind us to keep our skills sharp and honed. Invest in your Team shows that if you don't bother to spread your knowledge, they'll be unlikely to spread theirs with you, and if the goal is to deliver the best product we can to our customers, that just seems counterintuitive. Of course, it is just as important to Know When to Unlearn. Sure, that ASP solution you've had for 10 years works Ok, but that shouldn't stop you from exploring other new technologies. When you don't understand something, you should Question Until You Understand and finally Feel the Rhythm that Agile brings.

Now comes the contentious part. If our goal really is to deliver the most value to our customers that we can, then it makes sense that they should be able to drive the process. In Delivering What Users Want we hit some turbulent waters with topics like Let Customers Make Decisions, Let Design Guide, Not Dictate, and Fixed Prices are Broken Promises. But, to me, this is one of the most important chapters, and they do a good job of explaining how to accomplish all that with things like Getting Frequent Feedback, Automating Deployment Early, Integrate Early, Integrate Often, and Keep It Releasable. In addition, the use of Short Iterations and Releasing in Increments helps keep the flow going and communication with the customer high.

In order to keep up with the high level of customer communication (and confidence), you are going to need assurances your system is working properly. In Agile Feedback, Andy and Venkat discusses ways to get feedback in ways other than from your customer. At this point, if you've been on traditional projects, you are probably thinking the only way you could do this is with Angels on Your Shoulders, which they explain how to get with a safety net of automated unit tests. To really get a good sense of how to keep the design clean, they use techniques such as Use It Before You Build It and running it on a build machine other than your own since Different Makes a Difference. Finally, to understand how you are really doing, you have to Measure Real Progress which you can do through Automating Acceptance Testing (using something like FitNesse). Finally, you have to Listen To your Users. Similar to the way that you should treat compiler warnings as errors, customer complaints are a sign that something is wrong — especially if it is a high number of customers experiencing the problem.

Now that you are Agile with your customer, the authors begin to target the specific code you are writing in Agile Coding. This is a list of some key tenants of good development, such as Programming Intently and Expressively and Communicating in Code (and not chiefly through comments, either!). But there are some practices that are harder, but just as important like Keep It Simple, Actively Evaluate Trade-Offs and Code in Increments.

No matter how hard we try, though, defects still creep in. Or, we don't get the chance to work with pretty Greenfield code, but are dropped in the middle of a big ball of mud. How do we get out? In Agile Debugging, Andy and Venkat cover some great techniques including Warnings Are Really Errors (mentioned above), Report All Exceptions, and Provide Useful Error Messages (not like the ones found on The Daily WTF).

But one of the techniques was something I had not done before, and I thought was excellent — a Solutions Log (also called a Daylog). In other words, when you come across a problem, document it, and when you solve it, document it. No doubt, you'll come across that problem again, and when you do you'll be glad to be able to go back and figure out how you solved it — especially if you don't have the code you fixed it in the first time. (I have a tendency to record anything I come across that I know I will see again on my blog, and I tell you that typing a question into Google and the first result being your own website is the perfect way to make you feel like a total moron).

The final section, Agile Collaboration, is my idea of a dream team. First, you have to Schedule Regular Face Time to talk about what is going on in the project — especially if you all are working on the same code base! You have to be able to practice Collective Code Ownership (meaning anyone should have the knowledge to change another part of the system), and also means that Architects Should Write Code. To help grow the team, you can Be A Mentor, but to do it effectively you have to Allow People To Figure It Out. Some final practices are around respecting your team by Sharing Code Only When It's Ready, being available to Review Code, and Keeping Others Informed about what you've learned.

I enjoyed the layout of the chapters too. Each one starts with a "devil" which often times was saying something I've heard on one team or another. It finishes with an "angel",a nd a section of what it feels like to be doing the practice. Andy and Venkat also pepper the text with plenty of real world situations that reinforce just how bad software development can be.

In summary, if you want to be a better developer, but think Agile is a misused buzz word, go to your local bookstore, put a small piece of masking tape over the word "Agile" in the title, and buy this book. You won't regret it.

(1)Practies of an Agile Developer, pg. 17

Slashdot Top Deals

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"