Head First C#
Michael J. Ross writes "For computer programmers who do not have a solid understanding of object-oriented programming (OOP), learning the C# programming language can be rather challenging, even if they have experience with C or C++, which at least would give them a head start over non-C programmers. Any developer in this situation may well want to begin the learning process with a book that aims to teach both OOP and C# in as gentle a manner as possible, with plenty of patient explanations and illustrative diagrams — such as those found in the book Head First C# by Andrew Stellman and Jennifer Greene." Read below for the rest of Michael's review.
Head First C#
author
Andrew Stellman and Jennifer Greene
pages
778
publisher
O'Reilly Media
rating
7/10
reviewer
Michael J. Ross with Greg Hanson
ISBN
0596514824
summary
A heavily illustrated intro to object-oriented programming and C#
Published by O'Reilly Media on 26 November 2007, under the ISBNs 0596514824 and 978-0596514822, Head First C# is one in a series of "Brain-Friendly Guides." The introduction to this particular book discusses how the series attempts to present the concepts and technical material in a way that is far more intellectually compelling and memorable than the approach currently taken by most books. Some of their guiding principles include: making things visual, oftentimes using novel and even outlandish diagrams; using a casual and conversational style; engaging the reader through exercises and questions; and spicing up the discussions with humor.
On the book's Web page, readers will find links to download the book's sample code, participate in a forum dedicated to the book, register their copy of the book, read and submit any errata (of which there are many), and submit a reader review and read those of other readers.
The book's material is organized into 15 chapters, covering the topics in a progressive order that would probably be most helpful for the inexperienced developer: the advantages to programming visual applications in C# and the Microsoft Visual Studio integrated development environment (IDE); building a simple application to get started; the C# code produced by Visual Studio; basic C# language constructs; an introduction to objects and their components; data types, including arrays and references, and how C# allows you to work with them; protecting an object's data from unintended access, through encapsulation; extending classes through inheritance and subclasses; finding and using class interfaces, and the advantages of doing so; storing data in arrays, lists, and dictionaries; saving data in files and directories, as well as working with file streams and serialization; exceptions and debugging techniques; event handling; how to build complex applications; creating user interfaces with controls and graphics; object destruction and garbage collection; and connecting your C# programs to databases using LINQ. Interspersed throughout the book are three C# labs, which encourage the reader to put into practice their new programming skills, and thus better internalize the ideas of OOP and C# covered in the chapters preceding each lab. The lab applications comprise a racetrack simulator, a simple adventure game, and a re-creation of Space Invaders.
When they see this book for the first time, some prospective readers may be overwhelmed by its size, clocking in at 778 pages. Yet a sizable portion of those pages will read faster than those of the typical programming book, largely due to all of the diagrams and whitespace, which really help to break up the material and make it more digestible. However, what many might perceive to be a strength of the book, could be seen as a weakness by others. In fact, if the unnecessary diagrams and redundant material were to be removed from the book, it might end up only half its current size. But this may only be a deterrent for people who are carrying this book around, or who tend to be impatient and wish to get right to the point of any book they are reading, or who may be upset by the extra trees chopped down to double the number of pages (the book does not appear to have been printed on recycled paper).
Despite Head First C# being clearly intended as an introductory book to object-oriented programming in general, and C# in particular, the target audience especially may be frustrated by all of the errata and other sources of confusion that they will encounter. This is especially true when readers are doing their best to implement all of the sample applications, and struggling when, for instance, the code does not match the figure provided, or even the code on another page. For example, on page 50, the authors instruct the reader to drag a new PictureBox onto a new form, but readers will probably struggle to figure out where to drag it from. On page 105, the authors instruct the reader to flip back and look through the code, to fill in some class diagrams, but they don't clarify what code should be considered. Readers' comments on the online bookseller sites, list far more similar problems. In fact, that there are so many technical errors in this book is quite remarkable given that the technical review team comprised no fewer than 14 individuals! How could so many eyeballs miss so much?
The authors make a real point of reviewing material explained earlier, which generally is an effective approach for this type of book. But the repetition sometimes becomes excessive — enough to annoy even the greenest novice. For example, on page 445, we find the question: "Okay, I still don't get it. Sorry. Why are there so many different kinds of exceptions, again?"
On the other hand, the book has some real strengths, including those mentioned above for making the material more approachable. In particular, when the reader becomes accustomed to the visual style of presenting concepts, he or she will probably find it a faster approach to learning the ideas. Admittedly, veteran developers may still prefer the more narrative style of conventional programming books — especially when they encounter rather convoluted diagrams, such as that on page 292. Yet the illustrations are particularly potent for explaining interfaces, as done in Chapter 7.
Although the book will be of most value to newer programmers, experienced C# programmers will find topics of interest and perhaps even some language details and analysis that they have never previously encountered. For instance, some of the questions posed in the sections titled "there are no Dumb Questions," could be valuable — such as the comparison of File versus FileInfo, and when to use one over the other. Also, some of the utilities could help the reader for future development, such as the hex dumper program on page 432.
Sadly, Head First C# is weighed down by excessive redundancy and an errata-to-number-of-technical-reviewers ratio possibly unequaled by any other programming book. Yet, for any programmer new to object orientation and C#, this introductory book should prove an extremely comprehensible and reader-friendly resource.
Michael J. Ross is a Web developer, writer, and freelance editor. Contributor Greg Hanson is a C# programmer in Fort Collins, Colorado.
You can purchase Head First C# from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
On the book's Web page, readers will find links to download the book's sample code, participate in a forum dedicated to the book, register their copy of the book, read and submit any errata (of which there are many), and submit a reader review and read those of other readers.
The book's material is organized into 15 chapters, covering the topics in a progressive order that would probably be most helpful for the inexperienced developer: the advantages to programming visual applications in C# and the Microsoft Visual Studio integrated development environment (IDE); building a simple application to get started; the C# code produced by Visual Studio; basic C# language constructs; an introduction to objects and their components; data types, including arrays and references, and how C# allows you to work with them; protecting an object's data from unintended access, through encapsulation; extending classes through inheritance and subclasses; finding and using class interfaces, and the advantages of doing so; storing data in arrays, lists, and dictionaries; saving data in files and directories, as well as working with file streams and serialization; exceptions and debugging techniques; event handling; how to build complex applications; creating user interfaces with controls and graphics; object destruction and garbage collection; and connecting your C# programs to databases using LINQ. Interspersed throughout the book are three C# labs, which encourage the reader to put into practice their new programming skills, and thus better internalize the ideas of OOP and C# covered in the chapters preceding each lab. The lab applications comprise a racetrack simulator, a simple adventure game, and a re-creation of Space Invaders.
When they see this book for the first time, some prospective readers may be overwhelmed by its size, clocking in at 778 pages. Yet a sizable portion of those pages will read faster than those of the typical programming book, largely due to all of the diagrams and whitespace, which really help to break up the material and make it more digestible. However, what many might perceive to be a strength of the book, could be seen as a weakness by others. In fact, if the unnecessary diagrams and redundant material were to be removed from the book, it might end up only half its current size. But this may only be a deterrent for people who are carrying this book around, or who tend to be impatient and wish to get right to the point of any book they are reading, or who may be upset by the extra trees chopped down to double the number of pages (the book does not appear to have been printed on recycled paper).
Despite Head First C# being clearly intended as an introductory book to object-oriented programming in general, and C# in particular, the target audience especially may be frustrated by all of the errata and other sources of confusion that they will encounter. This is especially true when readers are doing their best to implement all of the sample applications, and struggling when, for instance, the code does not match the figure provided, or even the code on another page. For example, on page 50, the authors instruct the reader to drag a new PictureBox onto a new form, but readers will probably struggle to figure out where to drag it from. On page 105, the authors instruct the reader to flip back and look through the code, to fill in some class diagrams, but they don't clarify what code should be considered. Readers' comments on the online bookseller sites, list far more similar problems. In fact, that there are so many technical errors in this book is quite remarkable given that the technical review team comprised no fewer than 14 individuals! How could so many eyeballs miss so much?
The authors make a real point of reviewing material explained earlier, which generally is an effective approach for this type of book. But the repetition sometimes becomes excessive — enough to annoy even the greenest novice. For example, on page 445, we find the question: "Okay, I still don't get it. Sorry. Why are there so many different kinds of exceptions, again?"
On the other hand, the book has some real strengths, including those mentioned above for making the material more approachable. In particular, when the reader becomes accustomed to the visual style of presenting concepts, he or she will probably find it a faster approach to learning the ideas. Admittedly, veteran developers may still prefer the more narrative style of conventional programming books — especially when they encounter rather convoluted diagrams, such as that on page 292. Yet the illustrations are particularly potent for explaining interfaces, as done in Chapter 7.
Although the book will be of most value to newer programmers, experienced C# programmers will find topics of interest and perhaps even some language details and analysis that they have never previously encountered. For instance, some of the questions posed in the sections titled "there are no Dumb Questions," could be valuable — such as the comparison of File versus FileInfo, and when to use one over the other. Also, some of the utilities could help the reader for future development, such as the hex dumper program on page 432.
Sadly, Head First C# is weighed down by excessive redundancy and an errata-to-number-of-technical-reviewers ratio possibly unequaled by any other programming book. Yet, for any programmer new to object orientation and C#, this introductory book should prove an extremely comprehensible and reader-friendly resource.
Michael J. Ross is a Web developer, writer, and freelance editor. Contributor Greg Hanson is a C# programmer in Fort Collins, Colorado.
You can purchase Head First C# from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It's M$ goo. It's a "we lost our J++ lawsuit so we gonna rewrap our crap" thingy..
LFS. Have you built your system today?
Ouch, my eyeball!
and C and C++ are all good languages, but I like C@!&$. It's the $h!7.
Look where all this talking got us, baby.
Granted, in this case I don't know the language C#, but in general I never really understood the Head First series, unless you really like printed introductions to languages. It would just make more sense to use free Internet resources to take your first steps in C#, and then get O'Reilly's e.g. C# 3.0 in a Nutshell as a good desk reference. Tech books are expensive, so it just doesn't make sense to invest in a primer that, after you finish with it, is a paperweight.
This book happens to be in our club's collection. Someone gave it to us, I think I found it redundant, and times. but then, most language-centered programming books are, to a certain extent. The first person in our group who read it went through and hi-lighted the page numbers with redundant material on them in blue, and hi-lighted the important pages in yellow. We were able to learn the language's syntax and nuances without reading through long-winded explanations about core concepts in OO or reviews of concepts just covered that way. Generally, I've always found the "language bible" books more helpful than these types of books. Does anyone share my sentiment?
I always loved this series of books. My professor recommended this book to me and it has helped me understand the language much better then any other book. It's interesting, funny, and insightful! A very different take on presenting material then other programing books. As a college student I have a hard time reading through dull school text books. Sometimes I don't even have to open or own a text book in order to get through the class. Although you don't need to buy a book anymore to learn a language with the huge resources the internet has to offer.
A few years ago, when I was relatively new to programming, I read Head First Java and that really helped me understand the Java language and OOP in Java. Even if you aren't a beginner, the Head First books are still pretty decent, but make sure you have patience because most of the explanations/examples are "dumbed down" for the beginner. Also the harder stuff tends to be at the end of the book, so you can hold out for that.
I can vouch for this series, it totally rox. In fact, I don't know why more books don't focus on OOAD basics when teaching a language. If they did, then maybe I would know more "Senior Engineers" who have matured enough to stop focusing on code reuse and start focusing on design reuse.
Inheritance is so easy to misuse, more people should know that!
As an experienced programmer looking for a friendly intro to C#, I have enjoyed it, but I would have to concur that O'Reilly's C# in a Nutshell will be my day in day out reference. But, I am glad that O'Reilly is coming out with these user friendly references that make new concepts/languages more entertaining and fun. Head First Design Patterns is another one that some may fine easier to handle than the traditional Gang of Four book.
Yet, for any programmer new to object orientation...
How many can there be left these days?!? It's too easy to accumulate enough material for a good-sized book by starting from scratch and assuming the reader only knows how to read. Anyone could write a beginner's book on a computer language, without knowing the language too in depth, by just padding it with lots of remedial review material, that 99% of the readers don't need and don't want (to wade thru or pay for).
Attention zealots and haters: 00100 00100
...then chances are that was a deliberate decision. Good choice. OOP is the straitjacket that restrains new programmers from doing anything right.
Before you mark me troll, keep in mind that Linus Torvalds agrees with me. See here: http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
Why are books reviewed here like a year later than they where published?
And only negligibly less to program in C#. One wonders why the author believes learning C# would be so difficult for C++ programmers--unless he refers to the additional, unnecessary cognitive load that Micro$oft adds to whatever they excrete.
Why must a well designed language be challenging?
I came at Java with some C plus some experience with a (proprietary) object oriented AI system. Java was trivially easy to pick up.
Have gnu, will travel.
but this particular book doesn't do anyone any favors unless they are an absolute beginner. I picked it up when I started my current position (.NET shop, lots of C# and *shudder* classic ASP using VBScript) mainly because their books on Design Patterns and Servlets and JSPs were decent. I quickly discovered that if you know just about any other C-style variant that C# is a snap to pick up. This book does a great job of hand-holding and providing lots of examples of classic OO concepts, but I would never use it as a desk reference. Their style works very well for subjects which take some thought to wrap your head around (such as design patterns), but there is entirely too much noise to signal for learning a language for my taste. Personally I'd rather have quick access to the language reference and the pertinent APIs, but I suppose if someone was just getting started this book might be appropriate.
God, schmod. I want my monkey man!
Anonymous delegates came out in C# 2.0 (I think), and now we have lambda expressions. Umpteen ways to do delegates, and hardly anybody I know uses them and gets confused as heck when they see code I write that uses them. It's because F10 through the debugger "looks wierd" when you use them and people aren't used to seeing functions inside functions :-)
There's lots of stuff in C# that people never use.
Getting head first is the only way I'll program in C#!
"For computer programmers who do not have a solid understanding of object-oriented programming (OOP), learning the C# programming language can be rather challenging, even if they have experience with C or C++..."
If you are an experienced C++ developer who doesn't know enough about OOP to get by in C#, then I'd say you need more help than any mere book is going to provide.
For computer programmers who do not have a solid understanding of object-oriented programming (OOP), learning the C# programming language can be rather challenging, even if they have experience with C or C++
Well if you have "experience with C++" but no "solid understanding of OOP", there might already be a problem with your programming skills.
My first program:
Hell Segmentation fault
It's because C++ breaks programmers minds so badly in such a way that they feel like they have to overcomplicate everything using stupid template tricks and stupid pointer tricks.
C++ programmers who move to C# often fail to comprehend how overcomplicated they tend to make things.
These 700+ page books on programming languages have too much bloat. Usually because they're full of recipes, plus a rehash of introductory programming material.
A really well written 50 page book on C# would be more useful. Especially if it came with a little summary card with the syntax. Code examples should be on an associated web site.
Of course, it's a Microsoft product, so it has "strategic complexity", not minimalism.
Instead of teaching a subject by a massive 778 pages of text, you should go for the consise description of C# as described in Peter Sestoft and Henrik Hansens book:
http://www.amazon.com/C-Precisely-Peter-Sestoft/dp/0262693178
With 182 pages it is quickly read, yet you can also easily iterate over the text again and again as deeper and deeper understanding of C# is needed. A real gem on any developers bookshelf!
Thomas S. Iversen
Head first was pretty good, but I still prefer my old standby - "Balls Deep Into C#"
I mean, I can write a C# compiler in Java, can I not? Oh wait, I can write a Java compiler in C#. Holy crap, I can write anything in assembler. I just found the best language.
OMG, or, OMFG, Are you actually commenting on the book, or the review, or the publisher and not slamming C#? I am outraged. OUTRAGED! O U T R A G E D!
Sir, this is /.! Kindly start slamming C#, .NET, MS, Bill Gates, Bill and/or Melinda Gates, The Bill and Meliinda Gates Foundation, Ballmer, monkeys, chairs. But, sir, do not post on the book that was reviewed in the above article.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Seriously: trying to rot your brain? Cb is the most godawful language ever. It's made by Microsoft! Get a clue! There are only two OO languages. Smalltalk and Objective-C. Objective-C is dazzling. Cb is just more Microshite shite. Settle for 2nd best and YOU will be 2nd best. At best.
Last week we had that story about Textbook Torrents. This was one of the ones I found there!
None. The cool kids program in Java, Ruby, not C# C, C++, not C#, Scala, Groovy, not C#....
i think c# and M$ products are rubbish.. blah blah blah... Get a new line guys.
...and I guess someone who uses a wood chisel to open a paint can is a handyman. The differences between C++ polymorphism and C# interfaces are extreme and I find it baffling that someone who could claim even a passing familiarity with both languages could genuinely confuse the two.
Can someone please explain what is wrong with C#? Something other than the fact it was created by Microsoft or simply that it is 'rubbish'.
What features of the language do you have a problem with? Ok, so there's no multiple inheritance. What else?
I've been doing ASP.NET via C# for a living for about 18 months now, and I've found it to be a perfectly servicable language. What's the problem with it?
I hate Microsoft's business ethics just as much as the next /.er. I'm still going to judge their products based on their own merits.
Technoli
It's very windows orientated, but that's about all I find wrong with it. Not a problem if you're never leaving Windows land - I find it an excellent language. If you are going outside of Windows, pick a more suitable tool for the job or use mono.
throw new NoSignatureException();
But what strikes me as ignorant in your post is the OTHER HALF of your analogy.
Following your logic, you're saying:
"[Compared to C] none of those C++ features actually helps you write better programs, and a lot of the so-called improvements in C++ just make it a complicated mess."
I'm not a huge C++ fan. I'd rather have my teeth drilled than take apart a C++ template.
But to suggest that C++ was not substantive is, IMO, ignorant.
I think in both cases -- C++ and C# -- you'd benefit from looking at them as standalone languages and analyzing them from that POV.
Favored by BG, since it allows him to pick your pocket while getting the shaft.
My problem with C# is not in the language itself. It's in the fact that untold manhours have been utterly wasted in cloning Java.
Yes C# has some nice things Java does not have. And if Microsoft has worked with the Java community to add them, imagine what amazing things we could do with the language by now, the very advanced tools that would have arisen with a unifies choice of an essentially VM based language.
But because Microsoft suffers eternally from NIH, we all must suffer an industry a shadow of what it could be - from both the C# and Java side.
So basically I think using and promoting C# is like coughing on a sick man, just to see how long you can keep him in bed.
Nowadays I really can't understand why anyone uses ASP.NET for web development with some really interesting languages and frameworks like Rails and Pylons and umpteen interesting CMS systems all based on a variety of languages.
For Windows programming the choice is pretty clear since that's the way Microsoft is going.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
In Java x.y = a[b] could mean a few different things as well, if you throw in things like aspects, and many of the other things you mention have Java equivalents. Java extensions tend however to be more through frameworks than language extension which I think is a good thing if you do not want to end up like C++.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I hate these type of posts on Slashdot. They are just ads and really no different than spam.
Yeah for you dumb MS programmer fuckers who don't know what Object Oriented Programming is, don't get stressed, it's just "OOP". You know, OOP!!!
retards
-- A cat is no trade for integrity!
MS DID try it was called J#
That was not improving on Java, that was the first, even less veiled attempt to basically copy Java and add Microsoft specific stuff to it (like Win32 api's).
I don't personally think code readability is the be-all and end all of utilitiy, the ease of extension and quality of frameworks are far more important I think.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
My only issue is the lack of local static variables. If I'm searching a database for a record I like to check if I already have that record in scope. Ie. Find(int id){static int lastID = 0; if(id == lastID).... I've heard that the reason for this omission is because of threading and it's impact. Blaaa, if you're doing threading you should know better. Other then that. There's nothing wrong with the lang. Garbage collection isn't the devil I once thought it to be. Not if you look closely. The interpreted part of the lang will always bother me but on the whole for desk programming it's as good a lang as many and better them most.
Ok. The first c++ I ever got was deital and deital. Almost 10 years later and I still find it a fun read. I still see things in it I missed every other time. (perhaps I'm slow ). Their coverage of c# is huge. I mean 1300 pages is just too much. I'd have loved to see something more concise. That said I still bought the book. Seemed to me that if their c++ was great then their c# could be just as good.
Having come from a CB86 / Commodore BASIC / GFA BASIC / MS BASIC / GW-BASIC / QuickBASIC / VBDOS / VB background, I felt really sorry for all these C people who had to learn a whole new language again. All I had to learn was what an O did and how to orient it.
When I say complete novice, I mean a few weeks ago I couldn't read the most basic of code. I struggled and struggled to grasp some easy concepts (largely botched by the online tutorials I was trying to learn with). Then I purchased this book with the aid of my brother, who is a fairly experienced programmer, and finally I can write some fairly simple programs. No, this book isn't a reference book, and that will turn off a lot of vets - but it's meant for people like me. I can't emphasize how fantastic this book is - it's interesting, not a mind-numbingly dull read, and it's even made me laugh a few times.
I plan on using this book as a launch pad - hopefully, by the time I finish it, I will have a strong grasp on the fundamentals of C#. From that point I hope to contribute (if my skills are solid enough) to some OSS projects, and likely purchase a more in-depth, experienced-oriented book.
After struggling for weeks with crappy online tutorials, finding a novice oriented book was a dream come true.
Wouldn't that be the first one after the first, technically speaking? Speaking of which, as Head First is actually a series of books very similar in style, it would be nice to have someone elaborate on how much the authors re-use explanations, clip arts and examples their fellow authors already employed in Head First Java or the OO book.
Has anyone ever studied more than one of those books? However, I really like the approach, and I couldn't disagree more with the negative tone about the stated redundancy, because that's there on purpose. As those books are not meant as a reference but as a means of getting those language concepts into even the slightly ignorant minds (or the easily confused, or the easily distracted, your pick), repetition in slightly different wording is _great_.
A World in a Grain of Sand / Heaven in a Wild Flower,
Infinity in the Palm of your Hand / And Eternity in an Hour.
My only issue is the lack of local static variables. [...] I've heard that the reason for this omission is because of threading and it's impact. Blaaa, if you're doing threading you should know better.
Decades of evidence points to programmers not knowing better. No matter how much they should, they don't. You have to hit them with a pretty big stick to stop them from doing the lazy broken thing, and taking away local statics is just one more example of this. (Personally, I'd be tempted to much further and take away most state that's not thread-local, but that's not how C#, or Java or C++, works.)
"Little does he know, but there is no 'I' in 'Idiot'!"
This is a silly place to post a review about a C# book. Most of the readers here are way too narrow minded to post any reasonable discussion about the book (or anything involving M$).
The posts here pretty much prove my point. It's actualy kind of sad - it's obvious some of these people are fairly bright, yet they can't seem to see past their 'elitism' BS - which is anything but.
The review itself should probably be marked 'troll'.
I don't particularly like microsoft - but yep, I do code for a living in C# after having done so in Delphi (way back in delphi 1). And sorry guys, but it's pretty damn cool - the database access stuff needs work but in general, it's a very nice language to work with (and the IDE rocks). And yeah, well, as long as windows land is 90% of the world, that's where I'll be coding. Call me back when linux manages to get some desktop penetration worth talking about.
EK
I'd be more tempted to just take away their keyboard. I'm not a pro at threading and don't claim to be, it can be quite complex at times. That said I do understand data blocking. It's not really a hard concept. "Two people can not ride the same bike at the same time"... Tada!
I think putting protections in like these addresses one issue that affects a small part of the population and creates other issues.
Also the threading argument doesn't hold water. I can have class wide statics. This means that I could still create the same error.
Languages should not limit the programmer to protect them from themselves. It should allow us to shoot our foot off, if we so choose. They should be extensable. I think the loss of the local static was a mistake. One I have to work around (when needed) by exposing a method variable to the rest of the class. (not good)
If you're a n00b...Fine. If you're someone who codes for a living...the books are idiotic and really not that funny. I'm interested in learning, not being entertained. I find myself about every third page wanting to scream "JUST TELL ME WHAT THE F!#K I NEED TO KNOW!". But...then again...that's just my opinion.
Keep it up, trolltard. I guess you're down to this because the "game" wasn't as dreadfully easy as you calculated, eh?
You must have the Slashdot record of most ruined accounts, outside of the GNAA team. Impressive achievement.
And I'm including these as well, because I know that's you.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo