Agregador de canales de noticias
For many years, I have learned various subjects (mostly programming related, like languages and frameworks) purely by reading a book, blog posts or tutorials on the subjects, and maybe doing a few samples.
In recent years, I "learned" new programming languages by reading books on the subject. And I have noticed an interesting phenomenon: when having a choice between using these languages in a day-to-day basis or using another language I am already comfortable with, I go for the language I am comfortable with. This, despite my inner desire to use the hot new thing, or try out new ways of solving problems.
I believe the reason this is happening is that most of the texts I have read that introduce these languages are written by hackers and not by teachers.
What I mean by this is that these books are great at describing and exposing every feature of the language and have some clever examples shown to you, but none of these actually force you to write code in the language.
Compare this to Scheme and the book "Structure and Interpretation of Computer Programs". That book is designed with teaching in mind, so at the end of every section where a new concept has been introduced, the authors have a series of exercises specifically tailored to use the knowledge that you just gained and put it to use. Anyone that reads that book and does the exercises is going to be a guaranteed solid Scheme programmer, and will know more about computing than from reading any other book.
In contrast, the experience of reading a modern computing book from most of the high-tech publishers is very different. Most of the books being published do not have an educator reviewing the material, at best they have an editor that will fix your English and reorder some material and make sure the proper text is italicized and your samples are monospaced.
When you finish a chapter in a modern computing book, there are no exercises to try. When you finish it, your choices are to either take a break by checking some blogs or keep marching in a quest to collect more facts on the next chapter.
During this process, while you amass a bunch of information, at some neurological level, you have not really mastered the subject, nor gained the skills that you wanted. You have merely collected a bunch of trivia which most likely you will only put to use in an internet discussion forum.
What books involving an educator will do is include exercises that have been tailored to use the concepts that you just learned. When you come to this break, instead of drifting to the internet you can sit down and try to put your new knowledge to use.
Well developed exercises are an application of the psychology of Flow ensuring that the exercise matches the skills that you have developed and they guide you through a path that keeps you in an emotional state ranging that includes control, arousement and joy (flow). Anecdote Time
Back in 1988 when I first got the first edition of the "C++ Language", there were a couple of very simple exercises in the first chapter that took me a long time to get right and they both proved very educational.
The first exercises was "Compile Hello World". You might think, that is an easy one, I am going to skip that. But I had decided that I was going to do each and every single of one of the exercises in the book, no matter how simple. So if the exercise said "Build Hello World", I would build Hello World, even if I was already seasoned assembly language programmer.
It turned out that getting "Hello World" to build and run was very educational. I was using the Zortech C++ compiler on DOS back, and getting a build turned out to be almost impossible. I could not get the application to build, I got some obscure error and no way to fix it.
It took me days to figure out that I had the Microsoft linker in my path before the Zortech Linker, which caused the build to fail with the obscure error. An important lesson right there. On Error Messages
The second exercise that I struggled with was a simple class. The simple class was missing a semicolon at the end. But unlike modern compilers, the Zortech C++ compiler at the time error message was less than useful. It took a long time to spot the missing semicolon, because I was not paying close enough attention.
Doing these exercises trains your mind to recognize that "useless error message gobble gobble" actually means "you are missing a semicolon at the end of your class".
More recently, I learned in this same hard way that the F# error message "The value or constructor 'foo' is not defined" really means "You forgot to use 'rec' in your let", as in: let foo x = if x == 1 1 else foo (x-1)
That is a subject for another post, but the F# error message should tell me what I did wrong at a language level, as opposed to explaining to me why the compiler is unable to figure things out in its internal processing of the matter. Plea to book authors
Nowadays we are cranking books left and right to explain new technologies, but rarely do these books get the input from teachers and professional pedagogues. So we end up accumulating a lot of information, we sound lucid at cocktail parties and might even engage in a pointless engineering debate over features we barely master. But we have not learned.
Coming up with the ideas to try out what you have just learned is difficult. As you think of things that you could do, you quickly find that you are missing knowledge (discussed in further chapters) or your ideas are not that interesting. In my case, my mind drifts into solving other problems, and I go back to what I know best.
Please, build exercises into your books. Work with teachers to find the exercises that match the material just exposed and help us get in the zone of Flow.
Non-government controlled currency systems are now in vogue. Currencies that are not controlled by some government that might devalue your preciously earned pesos at the blink of an eye.
BitCoin is powered by powerful cryptography and math to ensure a truly digital currency. But it poses significant downsides, for one, governments can track your every move, and every transaction is stored on each bitcoin, making it difficult to prevent a tax audit in the future by The Man.
Today, I am introducing an alternative currency system that both keeps the anonymity of your transactions, and is even more secure than the crypto mumbo jumbo of bitcoins.
Today, I am introducing the MigCoin.
Like bitcoins, various MigCoins will be minted over time, to cope with the creation of value in the world.
Like bitcoins, the supply of MigCoins will be limited and will eventually plateau. Like bitcoin, the MigCoin is immune to the will of some Big Government bureaucrat that wants to control the markets by printing or removing money from circulation. Just like this:
Projected number of Bitcoins and MigCoins over time.
Unlike bitcoins, I am standing by them and I am not hiding behind a false name.
Like BitCoins, MigCoins come with a powerful authentication system that can be used to verify their authenticity. Unlike BitCoins, they do not suffer from this attached "log" that Big Brother and the Tax Man can use to come knocking on your door one day.
How does this genius of a currency work? How can you guarantee that governments or rogue entities wont print their own MigCoins?
The answer is simple my friends.
MigCoins are made of my DNA material.
Every morning, when I wake up, for as long as I remain alive, I will spit on a glass. A machine will take the minimum amount of spit necessary to lay down on a microscope slide, and this is how MigCoins are minted.
Then, you guys send me checks, and I send you the microscope slides with my spit.
To accept MigCoins payments all you have to do is carry a DNA sequencer with you, put the microscope slide on it, press a button, and BAM! 10 minutes later you have your currency validated.
To help accelerate the adoption of MigCoins, I will be offering bundles of MigCoins with the Ilumina MiSeq Personal DNA sequencer:
Some might argue that the machine alone is 125,000 dollars and validating one MigCoin is going to set me back 750 dollars.
Three words my friends: Economy of Scale.
We are going to need a few of you to put some extra pesos early on to get the prices to the DNA machines down.
Early Adopters of MigCoins
I will partner with visionaries like these to get the first few thousands sequencers built and start to get the prices down. Then we will hire that guy ex-Apple guy that was CEO of JC Penney to get his know-how on getting the prices of these puppies down.
Like Bitcoin, I expect to see a lot of nay-sayers and haters. People that will point out flaws on this system. But you know what?
The pace of innovation can not be held back by old-school economists that "don't get it" and pundits on CNN trying to make a quick buck. Hater are going to hate. 'nuff said.
Next week, I will be launching MigXchange, a place where you can trade your hard BitCoins for slabs of spit.
Join the revolution! Get your spit on!
We obtained some confidential information about the upcoming Facebook Phone. Here is what we know about it so far:
The FacebookPhone will be free (no contract) but will pause your call every 30 seconds to play an ad for 20— Miguel de Icaza (@migueldeicaza) March 29, 2013
Everyone will get an FacebookPhone to use as a honeypot trap for unwanted calls.— Miguel de Icaza (@migueldeicaza) March 29, 2013
@migueldeicaza it will also force a call to a person you haven't talked to in 10 years for every 5 calls you make.— Jonathan Chambers (@jon_cham) March 29, 2013
@migueldeicaza it'll use the ambient light sensor to detect when your not listening to the ad on your phone and just restart it— Alex Trott (@AlexTrott_) March 29, 2013
@migueldeicaza and ad calls cannot be muted, refused and the disconnect button will be suspended for the period of the call!...— Sumit Maitra (@sumitkm) March 29, 2013
@migueldeicaza the proximity sensor will be used to switch between earphone and speakerphone if it detects you've put the phone down!— Sumit Maitra (@sumitkm) March 29, 2013
@migueldeicaza Before you're able to call, you must finish a game of Farmville. When done, it asks "Do you wish to call *related friend*?"— Marco Kuiper (@marcofolio) March 29, 2013
The FacebookPhone will charge you 100 dollars to dial people who you have not friended— Miguel de Icaza (@migueldeicaza) March 29, 2013
@migueldeicaza After the call, a transcript and recording will be posted to your timeline, with the other party tagged.— Chris Howie (@cdhowie) March 29, 2013
@migueldeicaza it will have a single hardware button -'Like'— Martin Topping (@eMartinTopping) March 29, 2013
The FacebookPhone has no lock code, as privacy is just an illusion— Miguel de Icaza (@migueldeicaza) March 29, 2013
@migueldeicaza When you call someone, their phone will ring on the lowest volume unless you pay to "Promote" the call.— Brent Schooley (@brentschooley) March 29, 2013
@migueldeicaza It will also change the UI every week to expose features you don't use— Shmueli Englard (@Shmuelie) March 29, 2013
@migueldeicaza "The application 'My Friend Secrets' would like the following permissions: * Eavesdrop on all of your FacebookPhone calls."— Chris Howie (@cdhowie) March 29, 2013
While reading Dave Winer's Why Windows Lost to Mac post, I noticed many parallels with my own experience with Linux and the Mac. I will borrow the timeline from Dave's post.
I invested years of my life on the Linux desktop first as a personal passion (Gnome) and when while awoken for two Linux companies (my own, Ximian and then Novell). During this period, I believed strongly in dogfooding our own products. I believed that both me and my team had to use the software we wrote and catch bugs and errors before it reached our users. We were pretty strict about it: both from an ideological point of view, back in the days of all-software-will-be-free, and then practically - during my tamer business days. I routinely chastised fellow team members that had opted for the easy path and avoided our Linux products.
While I had Macs at Novell (to support Mono on MacOS), it would take a couple of years before I used a Mac regularly. In some vacation to Brazil around 2008 or so, I decided to only take the Mac for the trip and learn to live with the OS as a user, not just as a developer.
Computing-wise that three week vacation turned out to be very relaxing. Machine would suspend and resume without problem, WiFi just worked, audio did not stop working, I spend three weeks without having to recompile the kernel to adjust this or that, nor fighting the video drivers, or deal with the bizarre and random speed degradation that my ThinkPad suffered.
While I missed the comprehensive Linux toolchain and userland, I did not miss having to chase the proper package for my current version of Linux, or beg someone to package something. Binaries just worked.
From this point on, using the Mac was a part-time gig for me. During the Novell layoffs, I returned my laptop to Novell and I was left with only one Linux desktop computer at home. I purchased a Mac laptop and while I fully intended to keep using Linux, the dogfooding driver was no longer there.
Dave Winer writes, regarding Windows: Back to 2005, the first thing I noticed about the white Mac laptop, that aside from being a really nice computer, there was no malware. In 2005, Windows was a horror. Once a virus got on your machine, that was pretty much it. And Microsoft wasn't doing much to stop the infestation. For a long time they didn't even see it as their problem. In retrospect, it was the computer equivalent of Three Mile Island or Chernobyl.
To me, the fragmentation of Linux as a platform, the multiple incompatible distros, and the incompatibilities across versions of the same distro were my Three Mile Island/Chernobyl.
Without noticing, I stopped turning on the screen for my Linux machine during 2012. By the time I moved to a new apartment in October of 2012, I did not even bother plugging the machine back and to this date, I have yet to turn it on.
Even during all of my dogfooding and Linux advocacy days, whenever I had to recommend recommended a computer to a single new user, I recommended a Mac. And whenever I gave away computer gifts to friends and family, it was always a Mac. Linux just never managed to cross the desktop chasm.
We spent a year designing the new UI and features of Xamarin Studio (previously known as MonoDevelop).
I shared some stories of the process on the Xamarin blog.
After our launch, we open sourced all of the work that we did, as well as our new Gtk+ engine for OSX. Lanedo helps us tremendously making Gtk+ 2.x both solid and amazing on OSX (down to the new Lion scrollbars!). All of their work has either been upstreamed to Gtk+ or in the process of being upstreamed.