Wednesday, July 21, 2010

Nokia Kinetic Concept

http://www.jeremyinneshopkins.com/index.php?/product/nokia/

IT Digest as on 20-July-2010

Industry News

The Art of Trolling: Inside a 4chan Smear Campaign
"We are like... some kind of internet hate machine."
Source: Gawker

Antennagate: If you can’t fix it, feature it!
"Pity the poor schmoe who challenged Jobs to a verbal duel."
Source: Monday Note

David Blackwell, Scholar of Probability, Dies at 91
The first black scholar to be admitted to the National Academy of Sciences.|
Source: The New York Times

Five Ubuntu power tips
Friends don't let friends run as root.
Source: TechRepublic

Weekend Project: Install Web Apps in Chrome or Chromium
I hope your weekend was more exciting than this.
Source: Read Write Web

Android Development 101- Part 2:Graphical Elements
Adding a GUI and a "toast".
Source: Hack a Day

Microsoft puts IronPython, IronRuby under an Apache license
What does this really change?
Source: All About Microsoft

Windows Phone 7 in-depth preview
Judge for yourself.
Source: Engadget

Bomb-making tips, hit list behind Blogetery closure
One bad apple spoils the bunch.
Source: CNET

Bad Connection: Inside the iPhone Network Meltdown
"We're the phone company. We don't care, we don't have to."
Source: Wired

Developer News

What’s wrong with C++
Not enough GOTO.
Source: Code Improved

What To Know Before Debating Type Systems
Revisiting a classic.
Source: Steve's Blog

A re-introduction to JavaScript
"The world's most misunderstood programming language."
Source: Mozilla

Gems - Package Management For .NET
You can be cool just like the Ruby kids.
Source: devlicio.us

YubNub: The Web’s "Social Command Line"
Come out of your shell and join the party.
Source: WebWorkerDaily

A few things iOS developers ought to know about the ARM architecture
"On ARM, integer division is actually an operating system benchmark!"
Source: Wandering Coder

Breaking Up with IoC Containers
It's not you, it's me.
Source: Justin Bozonier's Blog

Multi-Core HTTP Server with NodeJS
Some tricks for getting JavaScript to scale.
Source: Yahoo! Developer Network

Kill hashtables, get shorter code
Functions gone bad.
Source: Ethan Herdrick

3 shell scripts to improve your writing
The [Elements] of <style>.
Source: matt.might.net


Android Devices Get Video Calling via Adobe

A new Adobe AIR demo is making the rounds today; it shows how Android phones can be used for user-to-user video calls.

Built using an upcoming release of AIR 2.5, this app is the Android (Android) and Adobe developer communities’ answer to FaceTime. The more generous in spirit would call this move “cheeky.” At any rate, it throws yet another log on the bonfire that is the Adobe-Apple public dialog.

The app was originally called “FlashTime,” but the name was changed to avoid some confusion.

Mark Doherty, Adobe’s Flash Platform Evangelist for mobile, said this isn’t an official release from Adobe; rather, it’s something he built over the course of three days to test the features of AIR 2.5 for Android. We’d love to show you his demo video here, but unfortunately, that clip is currently password-protected and not for public consumption.

Doherty doesn’t plan to release the app as a product, but he said he will open-source the code. He expects the code to be stable and finished by next week; interested parties should contact Doherty directly.

AIR and Flash for Android were announced first in February.

Android and Adobe as entities have been getting awfully chummy with one another ever since Apple declared war on Flash. With jingoistic barbs flying from all sides, it’s hard to have an unbiased, logical conversation uncolored by emotion when it comes to this subject. But without weighing in on one side or the other of the grander to-Flash-or-not-to-Flash debate, we can say that Android device users deserve the same ability to make video calls that iPhone 4 users now have, and we applaud the developers of any application that will help users have this ability.

One of the added bonuses of working on an open platform is that you can create apps like this and use the devices’ hardware in innovative, interesting and even “cheeky” ways without being blacklisted by the OS creator or device manufacturer. We can’t wait to see other Android video-calling apps in action.

What’s your opinion of this demo so far? Do you think more video-calling apps for Android phones will be coming up soon?

Courtesy: http://mashable.com/2010/07/20/android-video-calling/

What’s wrong with C++

…from the point of view of someone that actually uses it? The bits from my last post haven’t even dried up yet, and another fascinating rant about C++ has popped up, this time from Zed Shaw.

What’s interesting about these rants is that the ranter isn’t really using C++. They’re C hackers, or they program mostly in Python, or they used C++ at the beginning of the 90s. So I thought it would be interesting to write about my experience with C++.

First, a little background info…

I started learning C++ about 10 years ago, first the C part and then the ++ part. Nothing serious, just toying around with small projects to learn and have fun. I didn’t use it professionally until about four and a half years ago, when I started working on a large scale C++ project. Since then I’ve used it almost daily.

Two and a half years ago I came across Qt almost by accident: the large scale project that I was working on was being ported to Linux and the port was enabled by Qt. Since then, I’ve used Qt almost daily too.

Right now I’m working on a Qt C++ project that’s about 25KLOC in size and growing. It’s a multi-platform, threaded client-server and it’s a line of bussiness app if you’d believe it. Working on it is fun, and I’m glad that I picked Qt and C++.

Okay, enough with the history, what about C++ and its warts?

Issues that bother me in practice

  • Compile times and the include dependency specification: this is a problem that every C++ programmer will have sooner or later. It can be delayed and mitigated with a good physical design, precompiled headers and distributed compilers/linkers, but it can’t be solved without throwing away compatibility to existing code completely.
  • The small standard library: not a big issue in itself, since you can find other libraries for anything you might want to do, but it’s unpleasant to install all those libraries and make sure that they work together nicely. Using more libraries instead of a large standard library also means that you have to wait on each library vendor to port the library to different OSes/compilers, upgrade it and so on.
  • lack of reflection: I like Qt’s moc and I miss it in standard C++. I also wish it had more features.
  • lack of type inference: even with typedefs I’m typing more than I have to. C++0x will thankfully fix this.
  • localization & internationalization support in the standard library: the implementation is complicated and difficult to use. After browsing through C++ IOstreams and locales I’ve decided to just use Qt and not worry about it.
  • template error messages: they’re long and hard to understand. I usually parse a template error message in about 10-20 seconds depending on the difficulty. The worst offenders are metaprogramming-heavy libraries such as Boost Spirit. In that case, I try to analyze the code first and see what might be wrong. STLFilt can help.
  • functional programming support: this will get better in C++0x, but I can’t use C++0x now, at least not on all platforms and with the other libraries I’m using. Functors and free functions are cumbersome to use with algorithms.
  • tools and parsing: C++ has access to solid, mature tools, but those tools are much harder to develop than for other languages and generally don’t have as many features.

Issues that don’t bother me at all, but are regularly brought up in rants

  • memory management: never a problem for me. The last time I’ve had a memory leak was about two years ago and it got caught at code review. C++ has good support for memory management and good tools that can be used for runtime debugging. It might as well have GC, I wouldn’t be able to tell the difference.
  • memory corruption: memory corruption can be both exciting and scary. Exciting because you have to go down to the memory address level and do some sleuthing, scary because it can take days or weeks to find some bugs. I usually don’t sweat these bugs, they were very rare in the code I’ve worked on, and when they occurred they were easily found. e.g: the last one I’ve solved in maybe 30 seconds, the tools have gotten very good. The worst I’ve encountered was a problem with an embedded STL in a large project that took a week to figure out and only because of my lack of experience at that time. Some people love debugging.
  • multi-threading: it is hard in most languages. The trick is using higher-level libraries such as QtConcurrent, Intel’s TBB or OpenMP. Sure, if you’re doing PThreads it’s going to be painful.
  • string formatting and string support: I generally don’t use iostreams or std::string, but when I did I found them acceptable. Unicode support was the biggest issue, but “there’s a applib for that”. Now I use Qt’s strings and streams; they’re as easy to use as Python as far as I’m concerned. Don’t want Qt? Use boost::format or any other of the nice formatting libraries.
  • templates in general: I use them when needed to break dependencies, write generic code, etc. I try to keep template code manageable, without going into the metaprogramming stuff; they are one of my favourite C++ features.
  • exception rules: I don’t see any problem with exceptions in C++ as long as you’re using RAII. Other languages (e.g.: Python) use them extensively for error handling.
  • STL & Boost: I’ve used both for a lot of time and I find them very useful. Contrary to popular belief, most templates don’t use metaprogramming techniques. You don’t have to install Boost, it’s mostly headers. A large part of Boost became TR1 so it should even ship with your compiler now.
  • const: This one came from Zed, I don’t think I’ve seen that many people complain about const. Personally, I constify everything that I can, even const type* const.
  • everybody learns a different 10% of C++: strange, because I use all of it and always have. It’s not that hard either, I’m not a genius… Sane projects have coding guidelines and architectural documents. If your teammate can waltz right in with a template metaprogram or is generally macro-happy and it doesn’t raise eyebrows at code review, you have bigger problems than using C++. I’ve had to fix two C++ projects so far; my only job was to do what it takes to make the programs work and ship them to the customer. Most problems were memory leaks, superfluous use of casts, functions that didn’t compile on all platforms and so on. Fixable. What I couldn’t fix – and had to patch up as best as possible – were issues with the program logic and architecture. Those were not caused by C++.

Ok, but what about…

You probably have your favourite C++ misfeatures. Odds are that they don’t matter than much in practice, or workarounds are available. Maybe I just got used to them and consider them a C++ tax.

This article is from http://blog.codeimproved.net/2010/07/whats-wrong-with-c/