Search Results: "steele"

29 May 2020

Keith Packard: picolibc-string-float

Float/String Conversion in Picolibc Exact conversion between strings and floats seems like a fairly straightforward problem. There are two related problems:
  1. String to Float conversion. In this case, the goal is to construct the floating point number which most closely approximates the number represented by the string.
  2. Float to String conversion. Here, the goal is to generate the shortest string which, when fed back into the String to Float conversion code, exactly reproduces the original value.
When linked together, getting from float to string and back to float is a round trip , and an exact pair of algorithms does this for every floating point value. Solutions for both directions were published in the proceedings of the ACM SIGPLAN 1990 conference on Programming language design and implementation, with the string-to-float version written by William Clinger and the float-to-string version written by Guy Steele and Jon White. These solutions rely on very high precision integer arithmetic to get every case correct, with float-to-string requiring up to 1050 bits for the 64-bit IEEE floating point format. That's a lot of bits. Newlib Float/String Conversion The original newlib code, written in 1998 by David M. Gay, has arbitrary-precision numeric code for these functions to get exact results. However, it has the disadvantages of performing numerous memory allocations, consuming considerable space for the code, and taking a long time for conversions. The first disadvantage, using malloc during conversion, ended up causing a number of CVEs because the results of malloc were not being checked. That's bad on all platforms, but especially bad for embedded systems where reading and writing through NULL pointers may have unknown effects. Upstream newlib applied a quick fix to check the allocations and call abort. Again, on platforms with an OS, that at least provides a way to shut down the program and let the operating environment figure out what to do next. On tiny embedded systems, there may not be any way to log an error message or even restart the system. Ok, so we want to get rid of the calls to abort and have the error reported back through the API call which caused the problem. That's got two issues, one mere technical work, and another mere re-interpretation of specifications. Let's review the specification issue. The libc APIs involved here are: Input: Output: Scanf and printf are both documented to set errno to ENOMEM when they run out of memory, but none of the other functions takes that possibility into account. So we'll make some stuff up and hope it works out: Now, looking back at the technical challenge. That's a simple matter of inserting checks at each allocation, or call which may result in an allocation, and reporting failure back up the call stack, unwinding any intermediate state to avoid leaking memory. Testing Every Possible Allocation Failure There are a lot of allocation calls in the newlib code. And the call stack can get pretty deep. A simple visual inspection of the code didn't seem sufficient to me to validate the allocation checking code. So I instrumented malloc, making it count the number of allocations and fail at a specific one. Now I can count the total number of allocations done over the entire test suite run for each API involved and then run the test suite that many times, failing each allocation in turn and checking to make sure we recover correctly. By that, I mean: There were about 60000 allocations to track, so I ran the test suite that many times, which (with the added malloc tracing enabled) took about 12 hours. Bits Pushed to the Repository With the testing complete, I'm reasonably confident that the code is now working, and that these CVEs are more completely squashed. If someone is interested in back-porting the newlib fixes upstream to newlib, that would be awesome. It's not completely trivial as this part of picolibc has diverged a bit due to the elimination of the reent structure. Picolibc's Tinystdio Float/String Conversion Picolibc contains a complete replacement for stdio which was originally adopted from avr libc. That's a stdio implementation designed to run on 8-bit Atmel processors and focuses on very limited memory use and small code size. It does this while maintaining surprisingly complete support for C99 printf and scanf support. However, it also does this without any arbitrary precision arithmetic, which means it doesn't get the right answer all of the time. For most embedded systems, this is usually a good trade off -- floating point input and output are likely to be largely used for diagnostics and debugging, so mostly correct answers are probably sufficient. The original avr-libc code only supports 32-bit floats, as that's all the ABI on those processors has. I extended that to 64-, 80- and 128- bit floats to cover double and long double on x86 and RISC-V processors. Then I spent a bunch of time adjusting the code to get it to more accurately support C99 standards. Tinystdio also had strtod support, but it was missing ecvt, fcvt and gcvt. For those, picolibc was just falling back to the old newlib code, which introduced all of the memory allocation issues we've just read about. Fixing that so that tinystdio was self-contained and did ecvt, fcvt and gcvt internally required writing those functions in terms of the float-to-string primitives already provided in tinystdio to support printf. gcvt is most easily supported by just calling sprintf. Once complete, the default picolibc build, using tinystdio, no longer does any memory allocation for float/string conversions.

17 October 2017

Russ Allbery: Bundle haul

Confession time: I started making these posts (eons ago) because a close friend did as well, and I enjoyed reading them. But the main reason why I continue is because the primary way I have to keep track of the books I've bought and avoid duplicates is, well, grep on these posts. I should come up with a non-bullshit way of doing this, but time to do more elegant things is in short supply, and, well, it's my blog. So I'm boring all of you who read this in various places with my internal bookkeeping. I do try to at least add a bit of commentary. This one will be more tedious than most since it includes five separate Humble Bundles, which increases the volume a lot. (I just realized I'd forgotten to record those purchases from the past several months.) First, the individual books I bought directly: Ilona Andrews Sweep in Peace (sff)
Ilona Andrews One Fell Sweep (sff)
Steven Brust Vallista (sff)
Nicky Drayden The Prey of Gods (sff)
Meg Elison The Book of the Unnamed Midwife (sff)
Pat Green Night Moves (nonfiction)
Ann Leckie Provenance (sff)
Seanan McGuire Once Broken Faith (sff)
Seanan McGuire The Brightest Fell (sff)
K. Arsenault Rivera The Tiger's Daughter (sff)
Matthew Walker Why We Sleep (nonfiction)
Some new books by favorite authors, a few new releases I heard good things about, and two (Night Moves and Why We Sleep) from references in on-line articles that impressed me. The books from security bundles (this is mostly work reading, assuming I'll get to any of it), including a blockchain bundle: Wil Allsop Unauthorised Access (nonfiction)
Ross Anderson Security Engineering (nonfiction)
Chris Anley, et al. The Shellcoder's Handbook (nonfiction)
Conrad Barsky & Chris Wilmer Bitcoin for the Befuddled (nonfiction)
Imran Bashir Mastering Blockchain (nonfiction)
Richard Bejtlich The Practice of Network Security (nonfiction)
Kariappa Bheemaiah The Blockchain Alternative (nonfiction)
Violet Blue Smart Girl's Guide to Privacy (nonfiction)
Richard Caetano Learning Bitcoin (nonfiction)
Nick Cano Game Hacking (nonfiction)
Bruce Dang, et al. Practical Reverse Engineering (nonfiction)
Chris Dannen Introducing Ethereum and Solidity (nonfiction)
Daniel Drescher Blockchain Basics (nonfiction)
Chris Eagle The IDA Pro Book, 2nd Edition (nonfiction)
Nikolay Elenkov Android Security Internals (nonfiction)
Jon Erickson Hacking, 2nd Edition (nonfiction)
Pedro Franco Understanding Bitcoin (nonfiction)
Christopher Hadnagy Social Engineering (nonfiction)
Peter N.M. Hansteen The Book of PF (nonfiction)
Brian Kelly The Bitcoin Big Bang (nonfiction)
David Kennedy, et al. Metasploit (nonfiction)
Manul Laphroaig (ed.) PoC GTFO (nonfiction)
Michael Hale Ligh, et al. The Art of Memory Forensics (nonfiction)
Michael Hale Ligh, et al. Malware Analyst's Cookbook (nonfiction)
Michael W. Lucas Absolute OpenBSD, 2nd Edition (nonfiction)
Bruce Nikkel Practical Forensic Imaging (nonfiction)
Sean-Philip Oriyano CEHv9 (nonfiction)
Kevin D. Mitnick The Art of Deception (nonfiction)
Narayan Prusty Building Blockchain Projects (nonfiction)
Prypto Bitcoin for Dummies (nonfiction)
Chris Sanders Practical Packet Analysis, 3rd Edition (nonfiction)
Bruce Schneier Applied Cryptography (nonfiction)
Adam Shostack Threat Modeling (nonfiction)
Craig Smith The Car Hacker's Handbook (nonfiction)
Dafydd Stuttard & Marcus Pinto The Web Application Hacker's Handbook (nonfiction)
Albert Szmigielski Bitcoin Essentials (nonfiction)
David Thiel iOS Application Security (nonfiction)
Georgia Weidman Penetration Testing (nonfiction)
Finally, the two SF bundles: Buzz Aldrin & John Barnes Encounter with Tiber (sff)
Poul Anderson Orion Shall Rise (sff)
Greg Bear The Forge of God (sff)
Octavia E. Butler Dawn (sff)
William C. Dietz Steelheart (sff)
J.L. Doty A Choice of Treasons (sff)
Harlan Ellison The City on the Edge of Forever (sff)
Toh Enjoe Self-Reference ENGINE (sff)
David Feintuch Midshipman's Hope (sff)
Alan Dean Foster Icerigger (sff)
Alan Dean Foster Mission to Moulokin (sff)
Alan Dean Foster The Deluge Drivers (sff)
Taiyo Fujii Orbital Cloud (sff)
Hideo Furukawa Belka, Why Don't You Bark? (sff)
Haikasoru (ed.) Saiensu Fikushon 2016 (sff anthology)
Joe Haldeman All My Sins Remembered (sff)
Jyouji Hayashi The Ouroboros Wave (sff)
Sergei Lukyanenko The Genome (sff)
Chohei Kambayashi Good Luck, Yukikaze (sff)
Chohei Kambayashi Yukikaze (sff)
Sakyo Komatsu Virus (sff)
Miyuki Miyabe The Book of Heroes (sff)
Kazuki Sakuraba Red Girls (sff)
Robert Silverberg Across a Billion Years (sff)
Allen Steele Orbital Decay (sff)
Bruce Sterling Schismatrix Plus (sff)
Michael Swanwick Vacuum Flowers (sff)
Yoshiki Tanaka Legend of the Galactic Heroes, Volume 1: Dawn (sff)
Yoshiki Tanaka Legend of the Galactic Heroes, Volume 2: Ambition (sff)
Yoshiki Tanaka Legend of the Galactic Heroes, Volume 3: Endurance (sff)
Tow Ubukata Mardock Scramble (sff)
Sayuri Ueda The Cage of Zeus (sff)
Sean Williams & Shane Dix Echoes of Earth (sff)
Hiroshi Yamamoto MM9 (sff)
Timothy Zahn Blackcollar (sff)
Phew. Okay, all caught up, and hopefully won't have to dump something like this again in the near future. Also, more books than I have any actual time to read, but what else is new.

7 September 2016

Reproducible builds folks: Reproducible Builds: week 71 in Stretch cycle

What happened in the Reproducible Builds effort between Sunday August 28 and Saturday September 3 2016: Media coverage Antonio Terceiro blogged about testing build reprodubility with debrepro . GSoC and Outreachy updates The next round is being planned now: see their page with a timeline and participating organizations listing. Maybe you want to participate this time? Then please reach out to us as soon as possible! Packages reviewed and fixed, and bugs filed The following packages have addressed reproducibility issues in other packages: The following updated packages have become reproducible in our current test setup after being fixed: The following updated packages appear to be reproducible now, for reasons we were not able to figure out yet. (Relevant changelogs did not mention reproducible builds.) The following 4 packages were not changed, but have become reproducible due to changes in their build-dependencies: Some uploads have addressed some reproducibility issues, but not all of them: Patches submitted that have not made their way to the archive yet: Reviews of unreproducible packages 706 package reviews have been added, 22 have been updated and 16 have been removed in this week, adding to our knowledge about identified issues. 5 issue types have been added: 1 issue type has been updated: Weekly QA work FTBFS bugs have been reported by: diffoscope development diffoscope development on the next version (60) continued in git, taking in contributions from: strip-nondeterminism development Mattia Rizzolo uploaded strip-nondeterminism 0.023-2~bpo8+1 to jessie-backports. A new version of strip-nondeterminism 0.024-1 was uploaded to unstable by Chris Lamb. It included contributions from: Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches. disorderfs development Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches. tests.reproducible-builds.org Debian: We now vary the GECOS records of the two build users. Thanks to Paul Wise for providing the patch. Misc. This week's edition was written by Ximin Luo, Holger Levsen & Chris Lamb and reviewed by a bunch of Reproducible Builds folks on IRC.

10 July 2016

Bits from Debian: New Debian Developers and Maintainers (May and June 2016)

The following contributors got their Debian Developer accounts in the last two months: The following contributors were added as Debian Maintainers in the last two months: Congratulations!

9 May 2016

Russ Allbery: BookRiot's SF/F by Female Authors

A list by Nikki Steele of the 100 best SF and fantasy novels by female authors (in her subjective take), published on BookRiot, has been making the rounds, with people noting which of those they've read. These crop up from time to time, and I've always been tempted to do the work to track the list over time the way that I track award winners. I had some free time this afternoon, so went ahead and set that up (although I badly need to refactor or rewrite a lot of my review posting code). An extra advantage is that I can publish the list as a separate web page so that I don't spam RSS readers with a huge list. The list, annotated with ratings and reviews where I've read the books, is under the reviews section of my web site. As I have time, I may add more lists. I'm also (slowly) working on the project of adding all the nominees for major awards and annotating those, since often the short lists contain a lot of interesting material too. One big caveat for this list: Steele only lists the first book of series, and in many cases the first book isn't very good and is far from the best of the series. So you'll see some anomalous low ratings here for first books that improve later on.

27 September 2015

Lunar: Reproducible builds: week 22 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Packages fixed The following 22 packages became reproducible due to changes in their build dependencies: breathe, cdi-api, geronimo-jpa-2.0-spec, geronimo-validation-1.0-spec, gradle-propdeps-plugin, jansi, javaparser, libjsr311-api-java, mac-widgets, mockito, mojarra, pastescript, plexus-utils2, powerline, python-psutil, python-sfml, python-tldap, pythondialog, tox, trident, truffle, zookeeper. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues but not all of them: Patches submitted which have not made their way to the archive yet: diffoscope development The changes to make diffoscope run under Python 3, along with many small fixes, entered the archive with version 35 on September 21th. Another release was made the very next day fixed two encoding-related issues discovered when running diffoscope on more Debian packages. strip-nondeterminism development Version 0.12.0 now preserves file permissions on modified zip files and dh_strip_nondeterminism has been made compatible with older debhelper. disorderfs development Version 0.3.0 implemented a multi-user mode that was required to build Debian packages using disorderfs. It also added command line options to control the ordering of files in directory (either shuffled or reversed) and another to do arbitrary changes to the reported space used by files on disk. A couple days later, version 0.4.0 was released to support locks, flush, fsync, fsyncdir, read_buf, and write_buf. Almost all known issues have now been fixed. reproducible.debian.net disorderfs is now used during the second build. This makes file ordering issue very easy to identify as such. (h01ger) Work has been done on making the distributed build setup more reliable. (h01ger) Documentation update Matt Kraii fixed the example on how to fix issues related to dates in Sphinx. Recent Sphinx versions should also be compatible with SOURCE_DATE_EPOCH. Package reviews 53 reviews have been removed, 85 added and 13 updated this week. 46 packages failing to build from source has been identified by Chris Lamb, Chris West, and Niko Tyni. Chris Lamb was the lucky reporter of bug #800000 on vdr-plugin-prefermenu. Issues related to disorderfs are being tracked with a new issue.

1 April 2014

Russ Allbery: Review: Asimov's, September 2011

Review: Asimov's Science Fiction, September 2011
Editor: Sheila Williams
Issue: Volume 35, No. 9
ISSN: 1065-2698
Pages: 112
Due to various other life priorities, it's been quite a while since I read this magazine. Let's see if I can remember the contents well enough to review it properly. The editorial this issue was about the Readers' Awards. Vaguely interesting, but Williams didn't have much to add beyond announcing the winners. I'm very happy to see Rusch's "Becoming One with the Ghosts" win best novella, though. The Silverberg column was more interesting: some musings and pop history about the Japanese convention of a retired emperor and how that fit into national politics. Di Filippo's book review column is all about short story collections, continuing the trend of Di Filippo mostly being interested in things I don't care about. "The Observation Post" by Allen M. Steele: A bit of alternate history set during the Cuban Missile Crisis, but with airships. The protagonist was a radioman aboard a blimp that was patrolling the ocean for Russian vessels sailing to Cuba. A storm forces them down on an island, resulting in an encounter with some claimed tourists who may be Russian spies. The SFnal twist is unlikely to come as much surprise to an experienced reader, and the barb at the end of the story suffers from the same problem. I appreciate the ethical dilemma, but I've also seen it in lots of stories and have a hard time getting fully invested in another version of it. But the story is otherwise competently written. (6) "D.O.C.S." by Neal Barrett, Jr.: Everyone has an author or two that they just don't get. Barrett is one of mine, although this story is a bit less surreal than most of his. I'm fairly sure it's an odd twist on the "death panel" conspiracy theory given a fantastic twist, but it's not entirely forthright about what's going on. Possibly of more interest to those who like Barrett better. (5) "Danilo" by Carol Emshwiller: Emshwiller's stories are always distinctive and not quite like anyone else's, involving odd outsiders and their attempts to make sense of their world. This one involves, as is common, an out-of-the-way village. Lewella claims that she's going to be married to a stranger from the north. No one believes her, although they give her bridal gifts anyway, and then one day she takes her gifts and leaves. The protagonist follows her, to look after her. The rest of the story walks the boundary that Emshwiller often walks, leaving the reader unsure whether the characters are in touch with some deeper reality or insane and suffering, but the ending is even more ambiguous than normal and, at least for me, entirely unsatisfying. (4) "Shadow Angel" by Erick Melton: This is another retread of an old SF idea. This time, it's that piloting through hyperspace involves alternate modes of consciousness and has profound effects on the pilot. The risk of this sort of story is that it turns hallucinatory and a bit incoherent, and I think that happened here. I like the world-building; the glimmers of future politics and trade and the way he weaves alternate timelines into the story caught my interest. But the story wasn't quite coherent enough (although part of this may be reviewing it quite some time after I originally read it). Promising, but not clear, and without quite enough agency for the protagonist. (6) "The Odor of Sanctity" by Ian Creasey: I found this story more memorable. The conceit is that a future society has developed technology that allows the capture and replay of scents, which has created a huge market for special scent experiences and the triggering of memories. The story is set in the Philippines and revolves around a Catholic priest who takes the mission to the poor seriously. He's dying, and several people wonder if it is possible to capture the mythical odor of scantity: the sweet scent said to follow the death of a saint rather than the normal odor of human death. Creasey handles this idea well, blending postulated future technology, the practical and cynical world of the poor streets, and a balance between mystical belief and practical skepticism. Nothing in the story is that surprising, but I was happy with the eventual resolution. (7) "Grandma Said" by R. Neube: This story's protagonist is a cleanser on a frontier planet made extremely dangerous by a virulent alien fungus. It is almost always fatal and very difficult to eradicate. Vic's job is to completely sanitize anything that had been in contact with a victim and maintain the other rules of strict quarantine required to keep the fungal infection from spreading uncontrolled. Nuebe weaves world-building together with Vic's background and adds a twist in the form of deeply unhealthy responses to the constant stress of living near death. Well told, if a bit disturbing. (7) "Stalker" by Robert Reed: Reed has a knack for fascinating and disturbing stories, and this is an excellent example of the type. The protagonist is a manufactured companion who is completely devoted to its owner. Their commercial name is Adorers, but everyone calls them Stalkers. In this case, the protagonist's owner is a serial rapist and murderer; given that, and given how good Reed is at writing these sorts of stories, you can probably imagine how chilling it is. As usual, there is a sharp barb in the ending, and not the one I was expecting. Good if you can handle the graphic violence and disturbing subject material. (7) "Burning Bibles" by Alan Wall: This is an interesting twist on the spy thriller. A three-letter agency in charge of investigating possible terrorist plots becomes suspicious after a warehouse of Bibles burns in mysterious circumstances. The agent they send in is a deaf-mute with special powers of intuition. This prompted some eye-rolling, and there's a lot of magic disability powers here to annoy, but it's played mostly straight after that introduction. The rest is a fairly conventional spy story, despite special empathic powers, but it's one I enjoyed and thought was fairly well-written. (7) Rating: 6 out of 10

28 January 2012

Russ Allbery: Review: Effective Java, Second Edition

Review: Effective Java, Second Edition, by Joshua Bloch
Publisher: Addison-Wesley
Copyright: 2008
Printing: October 2009
ISBN: 0-321-35668-3
Format: Trade paperback
Pages: 319
Guy Steele, in the forward to this book, writes:
Programs, unlike spoken sentences and unlike most books and magazines, are likely to be changed over time. It's typically not enough to produce code that operates effectively and is readily understood by other persons; one must also organize the code so that it is easy to modify. There may be ten ways to write code for some task T. Of those ten ways, seven will be awkward, inefficient, or puzzling. Of the other three, which is most likely to be similar to the code needed for the task T in next year's software release?
Teaching this, as well as how to avoid being awkward, inefficient, or puzzling, is the goal of this book. Clearly communicating effective, idiomatic, and maintainable usage to a newcomer to a programming language is one of the hardest types of programming books to write. Books like this are therefore quite scarce. Most introductory texts do try to communicate some degree of basic usage, but they rarely go far beyond the syntax, and when they do that usage is rarely both well-defended and inobvious. Bloch takes the concept quite far indeed, going deep not only into the Java language but also into object-oriented software construction in general. Effective Java is modeled after Effective C++ by Scott Meyers, a book I've not read (due to the lack of need for C++ in my programming life), but which I've heard a great deal about. This means the book is organized into 78 numbered items, each of which provides specific advice and analysis about one area of Java. Examples include item 16, "Favor composition over inheritance," or item 33, "Use EnumMap instead of ordinal indexing." As you can see, they run the gamut from high-level design principles to specific coding techniques. This sort of book demands a lot of the author. Everyone has a coding style, and everyone can make usage recommendations, but the merits or lack thereof of specific recommendations are often only visible with substantial later experience. More than any other type of programming language book, this sort of usage guide must be written by a language expert with years of experience with both good and bad code in the language. This is where Effective Java shines. Joshua Bloch led the design and implementation of significant portions of the Java core libraries at Sun and is currently the chief Java architect at Google, but even without knowing that background, his expertise is obvious. Every item in this book is backed up with specific examples and justification, and Bloch quotes extensively from the Java core library to illustrate both the advantages of the techniques he describes and the problems that result when they're not followed. This is not an introductory book, which is one of the things that makes it so efficient and concise. It's a book aimed at the intermediate or advanced Java programmer and assumes you already know the language and the basic pitfalls. There are only a few items in here that would be obvious to most experienced programmers, and even there Bloch ties them back to specific issues in Java in ways that are illuminating. I would not have expected to learn something new from a chapter on a hoary old problem like avoiding float and double for precise values, but I did: Bloch discusses the available alternatives within Java and their tradeoffs and then makes useful specific recommendations. If, like me, you're an experienced programmer already but relatively new to Java, you still should not read this book first. You need a general introduction to the language and libraries and a few projects under your belt before you can appreciate it. (I personally started with Thinking in Java by Bruce Eckel and it served me well, although on several points of style Bloch disagrees with advice in Eckel's book, and I find Bloch's arguments convincing.) But I think this is one of the best possible choices for your second book on Java, in large part because Bloch will head off bad design and style decisions that you don't realize you're making and catch them before they become entrenched. I'm glad I read it as soon as I knew the language well enough to absorb it, and it's the sort of book that I'm likely to re-read sections of whenever I work on Java code related to those topics. It's not entirely obvious that you should take my advice about this sort of book, since I'm not a Java expert and don't have those years of experience with it. But I've checked the recommendation with other programmers I know who are experts, and I've never heard anything but praise for it. It's also one of the books recommended in Coders at Work, and Bloch is one of the people interviewed there, which carries a lot of weight with me. And, apart from that, any long-time programmer who cares about their craft builds an internal sense of aesthetics around what a well-written program should look like and finds themselves recognizing a similar sense in other people's code, even in languages with which they're not familiar. Bloch's recommendations and analysis feel right; one can immediately see how they improve maintainability and robustness, and some of the techniques he shows are elegant and beautiful. This is not a general programming book. It's specifically focused on the Java language, and much of it deals with specific suggestions on how to use Java's core libraries and language features. If you're not going to be writing code in Java, I can't really recommend it. But one of the things I loved about it is that, while talking about Java, Bloch also talks about object-oriented software construction: techniques for extending foreign libraries one does not control, API design, and the proper use of inheritance, among other topics.. That advice is some of the best object-oriented software design advice I've ever read. There isn't enough of it to recommend the book to people with no interest in Java, but this book has even made my C and Perl code better, and has helped me grasp the tradeoff between inheritance and composition in a deeper way than I ever had before. It's a lovely side bonus. If you're writing Java, read this book. If you're learning Java, don't read it first, but read it second, and more than once, or alongside a project where you can apply the advice. It's dense and efficient in the information that it conveys, which means there's more in a couple pages here than in thirty or forty pages of some of the sprawling introductory programming books. I did read it cover to cover, which is one of the better ways to get a sense of Bloch's more general advice on software construction, but you'll hit information overload and will want to return to it piecemeal to fully absorb it. And do get the second edition. I'm sure the first edition is available cheap used, but the additions of enums and generics to the Java language are hugely important and provide some of the most elegant and graceful techniques in the book. Rating: 9 out of 10

28 February 2010

Russ Allbery: Review: Coders at Work

Review: Coders at Work, by Peter Seibel
Publisher: Apress
Copyright: 2009
ISBN: 1-4302-1948-3
Format: Trade paperback
Pages: 601
Coders at Work is a collection of edited interviews by Peter Seibel (probably best known previously for his book Practical Common Lisp) of an eclectic and excellent collection of fifteen programmers. It opens with an interview with Jamie Zawinski (one of the original Netscape developers) and closes with Donald Knuth. In between, the interview subjects range in programmer generations from Fran Allen (who started at IBM in 1957) and Bernie Cosell (one of the original ARPANET developers) to Brad Fitzpatrick (LiveJournal founder and original developer). Techniques and preferences also range widely, including two people involved in JavaScript development and standardization (Brendan Eich and Douglas Crockford), a functional programming language designer and developer (Simon Peyton Jones), language designers and standardizers such as Guy Steele, and people like Dan Ingalls who have a different experimental approach to programming than the normal application development focus. All of the interviewees are asked roughly the same basic questions, but each discussion goes in different directions. Seibel does an excellent job letting the interview subjects shape the discussion. Two things immediately stood out for me about this book. First, it's huge, and that's not padding. There are just over 600 pages of content here, much of it fascinating. The discussions Seibel has are broad-ranging, covering topics from the best way to learn programming to history and anecdotes of the field. There's some discussion of technique, but primarily at the level of basic approaches and mindset. One typical question is how each programmer organizes their approach to reading code that isn't familiar with them. Each interviewee is also asked for book recommendations, for their debugging techniques, for their opinions on proving code correct, and how they design code. The participants are so different in their backgrounds and approaches that these conversations go in fifteen different directions. This is one of the most compelling and engrossing non-fiction books I've read. Second, the selection of interview subjects, while full of well-known names in the field, is not the usual suspects. While I'm interested in the opinions of people like Larry Wall and Guido van Rossum, I've already heard quite a lot about how they think about programming. That's material that Coders at Work doesn't need to cover, and it doesn't. Many of the interview subjects here are people I'd heard of only vaguely or not at all prior to this book, often because they work in an area of programming that I'm not yet personally familiar with. Those who I had heard of, such as L. Peter Deutsch, I often knew in only one context (Ghostscript in that case) and was unfamiliar with the rest of their work. This gives the book a great exploratory feel and a lot of originality. There is so much good material here that it's hard to give a capsule review. This is a book I'm highly likely to re-read, taking more detailed notes. There's entertaining snarking from Jamie Zawinski and Brendan Eich, fascinating history of the field (including in gender balance) from Fran Allen, and an intriguing interview with Joe Armstrong (creator of Erlang), who seems to have a far different attitude towards languages and libraries than the other interviewees. Every interview is full of gems, bits of insight that I now want to research or play with. A couple of examples come to mind, just to provide a feel of the sort of insights I took out of the book. In the interview with Joshua Bloch, who does a lot of work on library APIs, he mentions that empathy is one of the most important skills for designing an API. You have to be able to put yourself in the shoes of the programmer who's going to use the API and understand how it will feel to them. This came up in the context of a discussion about different types of programmers, and how programmers can be good at different things; the one who can do low-level deep optimization may not have that sense of empathy. Another example: Bernie Cosell talked about how he did debugging, and how he got a reputation for being a fantastic debugger who was able to fix just about anything. He confessed that he often reached a portion of the code that he didn't understand, that seemed too complex and tricky for what it was attempting to accomplish, and rather than trace through it and try to understand it, he just rewrote it. And after rewriting, the bug was often gone. It wasn't really debugging, but at the same time it's close to the more recent concept of refactoring. Several of the interview subjects commented on a subjective feeling of complexity and how when it gets too high that's a warning sign that code may need to be rethought and rewritten. A third example: I was fascinated by the number of interviewees who said that they used printf, assert, and eyeballs to debug rather than using any more advanced debugging tools. The former Lisp developers would often bemoan the primitiveness of tools like gdb, but many of them found that print statements and thinking hard about the code were usually all that's needed. (There was also a lot of discussion about test suites and test-driven development.) The general consensus was that concurrency problems were the hardest to debug; they made up a disproportional number of the responses to Seibel's question about the hardest bug the programmer ever had to track down. I could go on giving similar examples at great length, but apart from the specific bits of wisdom, the strongest impact this book made on me was emotional. Coders at Work is full of people who love programming and love software, and that enthusiasm, both in general and for specific tools and ideas, comes through very clearly. I found it inspiring. I realized while reading this book, and I suspect I'm not alone among programmers in this, that I largely stopped learning how to program a few years back and have been reusing skills that I already have. Reading Coders at Work gave me a strong push towards finding ways to start learning, experimenting, and trying new techniques again. It also filled me with enthusiasm for the process of programming, which immediately helped my productivity on my own coding projects. This is obviously a book whose primary target audience is practicing programmers, and while it doesn't go too far into language theory, I was relying on remembered terms and structure from my master's degree for a few of the interviews. I think it's approachable for anyone who has a working background in programming and a few languages or a CS degree, but it might be a stretch for someone new to the field. But even someone without any programming knowledge at all would get a lot out of the anecdotes and snapshots of the history of software development. Coders at Work is also full of jumping-off points for some additional research on Google or additional reading in other recommended books. I only have one complaint, which I have to mention in passing: for such a large book full of interesting ideas and book recommendations, the index is wholly inadequate. I tried looking up five or six things in it, including the source of some of the book recommendations that are collected in an appendix, and I struck out every time. It's very hard to find something again in 600 pages, and more attention paid to the index would have been greatly appreciated. But, despite that, for people within the target audience, I cannot recommend this book too highly. Not only was it full of useful information, at the level of programming above the code details that's often the hardest to talk about, but it's consistently entertaining and emotionally invigorating and inspiring. It made the rounds of tech blogs when it was first released, to nearly universal approval, and I can only echo that. If you're a practicing programmer, I don't think you'll regret spending a few weeks reading and thinking about this book. Rating: 10 out of 10

3 February 2009

Aigars Mahinovs: Superbowl 2009

It has become a hidden tradition for me to watch Superbowl every year, despite disappointment in the game and coverage quality in the years before. It started as before: pre-game show, pre-pre-game show, coin toss show and kick-off show It is clear that the show is planned by and for advertisers and not for the viewers. That is a shame and a disgrace - the viewer must be the master of the TV programming and NOT the advertisers. In soccer the program starts, you see the captains exchange a handshake, you see the referee throw a coin and 10-15 seconds later the game is going full steam. Why do you need 3 ad breaks and 2 songs before the game is beyond me - get to the game! The camera work and NBC commentary is MUCH better than last year - stable shots with good close-ups and explanations that actually make sense even to people that are not American football experts. Oh and they actually use units - saying they won x out of y games this season and not they are x in y this season , mostly at least. The game had more fun than usual in the beginning, but the legal things slow it up again - it is weird that a guy got over the line but was called beck because of the knee touching and then a penalty for a false start ? Too much rules and regulations. Soon you ll have a team of lawyers on the sidelines and lawyer drafts will be more important than player drafts. And then again holding and chopping - isn t that what the blockers are supposed to do? Is that some kind of sissy sport? Maybe not. 100 yard interception return run I am speechless. Now that was a great, great play. That episode alone made watchig this thing worth it. Not the best sport thing I ve seen, but the best American football moment for sure. I like the basis of the game, it is a good game, but there is way too much fluff on it. That game needs to be cut down - less rules, less breaks, less interruption, less advertisements, less time to think and relax for the players. 10 seconds of play and 5 minutes of players chatting is not a sport, even curling has more action. The whole Superbowl should be over in 1 hour real time. If the TV transmission starts at 17:00, it should be done before 18:00. There is no content there to justify anything longer than that. Why is there a limited number of challenges? Do the referees make only a limited number of mistakes per game? No. Illogical. And when I though it was done and sealed, Arizona does a great drive and get a great touchdown. One more drive like that and the game could go either way. Now that is a good game. But again penalties spoil the whole game Fitsgerald gets a touchdown, another great play to turn the game around, but only because of the holding penalty giving Arizona safety score. Not deserving in my opinion. And the Steelers drive back AMAZING game! Now this is actually close to the best sports game that I have ever seen. I sure was not expecting that. And Arizona tries to drive back again. I was sleepy when I started to watch this, no sleep now. That was a great game. Despite all the commercialization, it is still a great game and it is very watchable if you download it from the Internet or watch it with TiVo and can skip the adds and the slow parts.

8 February 2006

Aigars Mahinovs: Superball/bowl. So ... I tried to understand what ...

Superball/bowl.
So ... I tried to understand what this american football thing is all about. What got me interested in it was an anime from Japan called Eyeshield 21 where a boy that ran errants for bullies his whole school life goes into american football as a runner with his great speed and agility. That get me thinking about looking into that sport - it looked quite interesting in the anime.
Boy was I wrong.
So I watched the Superbowl XL - the biggest and most important event in the american football year. The first half was absolutely empty - nothing happened at all. The ads were much more interesting then the game. The halftime show was ok, not as good as ads.
And the second half just showed why this is the definitive american sport in the worst meaning of that - legalese. Steelers would have lost it the judges would have not interfered so much with the game. This sport has like hundreds of tiny rules that are very dependent on interpretation by the judges - that is what I call a sport for all the american lawyers to like. Cancelling several good Seahawks trows just because some guy was holding someone on the other part of the field, that must be givin an ecstasy for every law student. Not for me though.
And even without all that dilation with ridiculous rules (what's that stupidity with running clock and two minute warning ?!?) the game itself is kind of dumb - there are just too many people in the field for anything that a regular person can really understand. Strategies that almost never work out because of the other team interfering with their strategy. Too much chaos and still each person only does a one single thing. Even more - many of the players never will get any attention in the game just because they are on a supporting position, but the quarterback will always be the center of attention.
A very unbalanced game that is even more screwed by a ton of ads, a very heavy leaning on judging nitpicks and just 3-4 nice moments in the whole 1 hour game. I'll just stick back with hockey and anime :)

20 January 2006

Sean Harshbarger: 20 Jan 2006

So long time I know. For those of you out there who celebrate, Merry Christmas and Happy New Year! I have been busy last month and a half with work. As many know, I work for UPS and mid-Nov. to Dec. get pretty hairy at that place. Back in school this quarter full time. I am determined to get this over with and get into the field most here in cyberspace know I want to be in. Looks like my days of hacking are going to have to wait tho. This week alone I have spent 6 hours a day in the books, 8 hours at work and the remainder in bed or wasting on tv/ps2. Back to college life again. Least I am not eating ramen again. Sunday I will be in Wellington Ohio for a 20 team paintball tournament. I am hoping to get pictures and video of the event and hope to post those somewhere are the net for all to see. It looks as if our local team has a good chance to win $1000 as long as I carry the team ;) At any rate, will be fun and those who know me know paintball is the only stress relief I have left. GO STEELERS!!!

15 January 2006

Brian Nelson: Post-game bitterness

Dear Pittsburgh Steelers, Please snap one of Peyton Manning’s legs like a twig tomorrow, much like you did to Carson Palmer last week. It’s the only thing that’ll make me feel better after sufferring through the Patriots game, watching the referees and Patriot players alternate giving away touchdowns to the Broncos. Thank you,
Brian Nelson

14 January 2006

Holger Levsen: I love statistics

arrrrrrrgggghhhh !