The Ranger's shared items in Google Reader

Nokia toob suvel turule oma tahvelarvuti

erruudised@err.ee — Wed, 16 Nov 2011 00:44:00 PST

Soome mobiilitootja Nokia kavatseb järgmise aasta juunis turule tuua oma esimese tahvelarvuti.

Loe edasi >

Viirus levitab Facebookis pornot ja vägivaldseid pilte

erruudised@err.ee — Tue, 15 Nov 2011 06:17:00 PST

Facebook tegeleb kaebustega, et suhtlusvõrgustikku on viimasel ööpäeval postitatud pornograafilisi ja vägivaldseid pilte, mis ilmuvad kasutajate uudisvoogu.

Loe edasi >

Swedbank tahab netipanga serverid Rootsi viia, eksperdid näevad ohtu

erruudised@err.ee — Sun, 13 Nov 2011 22:36:00 PST

Riigi infosüsteemi ameti (RIA) küberturbe spetsialiste on viimastel nädalatel ärevaks teinud Eestis tegutsevate pankade plaanid, mille kohaselt tahetakse serverikeskused omavahel ühendada ja seda muidugi panga koduriigis.

Loe edasi >

Your users don't care if you use Web Sockets

Scott Hanselman — Wed, 09 Nov 2011 12:43:40 PST

I had a lovely time at the Keeping It Realtime Conference this week in Portland. The conference was put on by the lovely folks over at &yet and I'm glad I met them. "KRTConf" was a whole conference dedicated to "real-time" web applications. This largely meant node but also other real-time frameworks including Damien and David's SignalR that Paul Batum (Paul owns Web Sockets for .NET) and I presented. I'll blog our demo soon.

Some folks in the audience wanted to make a real-time app today but really wanted to use Web Sockets today and had concerns about broad support. Coincidentally, I had just visited &yet's new site for product called "&!" or "AndBang," a collaboration tool for teams. However, when I visited the page I got this message: https://andbang.com/you-need-websockets-yo.

In the near future, all browsers and servers will support Web Sockets, a technique by which a persistent connection is negotiated over HTTP and then a protocol switch happens from http:// to ws://. However, not every browser or server is there yet (IE9, for example) and there's some arguing about versioning, etc. If you don't support Web Sockets, falling back to "Long Polling" is a way to get effectively the same behavior that works everywhere.

Long polling is a technique that lets it look like your browser has a "persistent connection" to the server when in fact you've just got a really "persistent client." By this I mean, rather than a connection that doesn't shut down (persistent) you have a client that will make a call and when it completes, it'll call back. The very definition of persistent, eh? See what I did there?

Persistent: Continuing firmly or obstinately in a course of action in spite of difficulty or opposition.

Long Polling is not as efficient but it works nicely and is a totally reasonable fallback when Web Sockets support is unavailable. The latest preview release of IE10 includes Web Sockets support. But my mom doesn't know about Web Sockets and shouldn't have to.

The 10,000 people on the planet that care about Web Sockets are not your customers, and while using Web Sockets might get you mentioned on TechCrunch, supporting only Web Sockets is a great way to cut your potential audience in half.

You can use the lovely CanIUse web site to find out if you browser supports something you'd like to use. Here's their Web Sockets table.

Your users don't care about Web Sockets. They care about delightful sites. We use JavaScript polyfills when our browsers don't support HTML5 features we want. We use jQuery when JavaScript support is dodgy between browsers. And our web frameworks should gracefully fallback to use Long Polling when Web Sockets isn't available.

Solving the Shakespeare Million Monkeys Problem in Real-time with Parallelism and SignalR

Scott Hanselman — Fri, 11 Nov 2011 17:09:22 PST

A little over 18 months ago I was talking to Stephen Toub (he of the Parallel Computing fame) about parallelism and the kinds of problems it could solve.

I said, naively, "could we solve the million monkey's problem?"

He said, "the what?"

"You know, if you have an infinite number of monkeys and an infinite number of keyboards they will eventually write Shakespeare."

We brainstormed some ideas (since Stephen is a smarter than I, this consisted mostly of him gazing thoughtfully into the air while I sat on my hands) and eventually settled on an genetic algorithm. We would breed thousands of generations of (hypothetical) monkeys a second and then choose which ones would be allowed to perpetuate the species based solely on their ability to write Shakespeare.

We used the .NET 4 Task Parallel Library to make it easier for the algorithm to scale to available hardware. I mean, anyone can foreach over a million monkeys. But loops like that in parallel over 12 processors takes talent, right? Well, kinda. A lot of it is done for you by the Parallelism Features in .NET and that's the point. It's Parallel Processing for the Masses.

We created a WinForms version of this application and I've used it on and off to demonstrate parallel computing on .NET. Then Paul Batum and I went to the Keeping It Realtime conference to demonstrate SignalR this last week. I didn't want to do the same "here's a real-time chat app" or "here's a map that shows its results in real-time" demos that one always does at these kinds of things. I suggested that we port our WinForms Shakespeare Monkey demo to ASP.NET and SignalR and that's what Paul proceeded to do.

When doing something that is crazy computationally intensive but also needs to return real-time results you might think to use node for the real-time notification part and perhaps spawn off another process and use C or something for the maths and then have them talk to each others. We like node and you can totally run node on IIS or even write node in WebMatrix. However, node is good at some things and .NET is good at some things.

For example, .NET is really good at CPU-bound computationally intensive stuff, like, I dunno, parallel matrix multiplication in F# or the like. ASP.NET is good at scaling web sites like Bing, or StackOverflow. You may not think IIS and ASP.NET when you think about real-time, but SignalR uses asynchronous handlers and smart techniques to get awesome scale when using long-polling and scales even more in our labs when using an efficient protocol like WebSockets with the new support for WebSockets in .NET 4.5.

So, we wanted to see if you combined asynchronous background work, use as many processors as you have, get real-time status updates via SignalR over long-polling or Web Sockets, using C#, .NET 4.5, ASP.NET and IIS.

It takes about 80,000 generations of monkeys at thousands of monkey generations a second (there's 200 monkeys per generation) to get the opening line of Hamlet. So that's ~16,000,000 monkeys just to get this much text. As they say, that's a lot of monkeys.

Here's the general idea of the app. The client is pretty lightweight and quite easy. There's two boxes, two buttons and a checkbox along side some text. There's some usual event wireup with started, cancelled, complete, and updateProgress, but see how those are on a monkey variable? That's from $.connection.monkeys. It could be $.connection.foo, of course, as long as it's hanging off $.connection.

Those functions are client side but we raise them from the server over the persistent connection then update some text.

<script src="Scripts/jquery-1.6.4.min.js"></script>    
<script src="Scripts/json2.min.js"></script>
<script src="Scripts/jquery.signalR.min.js"></script>
<script src="signalr/hubs"></script>
<script>
    $(function () {
        $('#targettext').val('To be or not to be, that is the question;\nWhether \'tis nobler in the mind to suffer\n\The slings and arrows of outrageous fortune,\n\Or to take arms against a sea of troubles,\n\And by opposing, end them.');

        var monkeys = $.connection.monkeys,
            currenttext = $('#currenttext'),
            generationSpan = $('#generation'),
            gpsSpan = $('#gps');

        monkeys.updateProgress = function (text, generation, gps) {
            currenttext.val(text);
            generationSpan.text(generation);
            gpsSpan.text(gps);
        };

        monkeys.started = function (target) {
            $('#status').text('Working...');
            $('#targettext').val(target);
            $('#cancelbutton').removeAttr('disabled');
        };

        monkeys.cancelled = function () {
            $('#status').text('Cancelled');
            $('#cancelbutton').attr('disabled', 'disabled');
        };

        monkeys.complete = function () {
            $('#status').text('Done');
            $('#cancelbutton').attr('disabled', 'disabled');
        };

        $.connection.hub.start({}, function () {
            $('#startbutton').click(function (event) {
                $('#status').text('Queued...');
                monkeys.startTyping($('#targettext').val(), $('#isparallel').is(':checked'));
            });

            $('#cancelbutton').click(function (event) {
                monkeys.stopTyping();
            });
        });

    });
</script>

The magic start with $.connection.hub.start. The hub client-side code is actually inside ~/signalr/hubs. See how that's include a the top? That client-side proxy is generated based on what hub or hubs are on the server side.

The server side is structured like this:

[HubName("monkeys")]
public class MonkeyHub : Hub
{
    public void StartTyping(string targetText, bool parallel)
    {
    }

    public void StopTyping()
    {
    }

}

The StartTyping and StopTyping .NET methods are callable from the client-side via the monkeys JavaScript object. So you can call server-side C# from the client-side JavaScript and from the C# server you can call methods in JavaScript on the client. It'll make the most sense if you debug it and watch the traffic on the wire. The point is that C# and Json objects can flow back and forth which blurs the line nicely between client and server. It's all convention over configuration. That's how we talk between client and server. Now, what about those monkeys?

You can check out the code in full, but StartTyping is the kick off point. Note how it's reporting back to the Hub (calling back to the client) constantly. Paul is using Hub.GetClients to talk to all connected clients as broadcast. This current implementation allows just one monkey job at a time. Other clients that connect will see the job in progress.

public void StartTyping(string targetText, bool parallel)
{
    var settings = new GeneticAlgorithmSettings { PopulationSize = 200 };
    var token = cancellation.Token;

    
    currentTask = currentTask.ContinueWith((previous) =>
    {
        // Create the new genetic algorithm
        var ga = new TextMatchGeneticAlgorithm(parallel, targetText, settings);
        TextMatchGenome? bestGenome = null;
        DateTime startedAt = DateTime.Now;

        Hub.GetClients<MonkeyHub>().started(targetText);

        // Iterate until a solution is found or until cancellation is requested
        for (int generation = 1; ; generation++)
        {
            if (token.IsCancellationRequested)
            {
                Hub.GetClients<MonkeyHub>().cancelled();
                break;
            }

            // Move to the next generation
            ga.MoveNext();

            // If we've found the best solution thus far, update the UI
            if (bestGenome == null ||
                ga.CurrentBest.Fitness < bestGenome.Value.Fitness)
            {
                bestGenome = ga.CurrentBest;
                
                int generationsPerSecond = generation / Math.Max(1, (int)((DateTime.Now - startedAt).TotalSeconds));
                Hub.GetClients<MonkeyHub>().updateProgress(bestGenome.Value.Text, generation, generationsPerSecond);

                if (bestGenome.Value.Fitness == 0)
                {
                    Hub.GetClients<MonkeyHub>().complete();
                    break;
                }
            }
        }                
    }, TaskContinuationOptions.OnlyOnRanToCompletion);
}

If he wanted, he could use this.Caller to communicate with the specific client that called StartTyping. Inside ga.MoveNext we make the decision to go parallel or not based on that checkbox. This is where we pick two random high quality parent monkeys from our population for a potential future monkey. Hopefully one whose typing looks more like Shakespeare and less like a Regular Expression.

By simply changing from Enumerable.Range to ParallelEnumerable.Range we can start taking easily parallelizable things and using all the processors on our machine. Note the code is the same otherwise.

private TextMatchGenome[] CreateNextGeneration()
{
    var maxFitness = _currentPopulation.Max(g => g.Fitness) + 1;
    var sumOfMaxMinusFitness = _currentPopulation.Sum(g => (long)(maxFitness - g.Fitness));

    if (_runParallel)
    {
        return (from i in ParallelEnumerable.Range(0, _settings.PopulationSize / 2)
                from child in CreateChildren(
                    FindRandomHighQualityParent(sumOfMaxMinusFitness, maxFitness),
                    FindRandomHighQualityParent(sumOfMaxMinusFitness, maxFitness))
                select child).
                ToArray();
    }
    else
    {
        return (from i in Enumerable.Range(0, _settings.PopulationSize / 2)
                from child in CreateChildren(
                    FindRandomHighQualityParent(sumOfMaxMinusFitness, maxFitness),
                    FindRandomHighQualityParent(sumOfMaxMinusFitness, maxFitness))
                select child).
                ToArray();
    }
}

My 12 proc desktop does about 3800 generations a second in parallel.

Big thanks to Paul for the lovely port of this to SignalR and to Stephen Toub for the algorithm.

The code for the SignalR monkeys demo is on my BitBucket. Right now it needs .NET 4.5 and the Visual Studio Developer Preview, but you could remove a few lines and get it working on .NET 4, no problem.

Note that that SignalR works on .NET 4 and up and you can play with it today. You can even chat with the developers in the SignalR chat app in the 'aspnet' room at http://chatapp.apphb.com. Just /nick yourself then /join aspnet.

No monkeys were hurt in the writing of this blog post.

Even 12 Year Olds Can Write Their Own Justin Bieber Apps

Adam Popescu — Tue, 08 Nov 2011 06:30:00 PST

While it's widely accepted that most 12-year-olds are comfortable using iPhone apps, it's not common that many 12-year-olds can code up their own. Meet Thomas Suarez, who has created two of his own. Both are distributed by Carrot Corp, the startup Thomas founded, but cannot legally own because he's under 18 (his father is listed as the company's president). Hundreds of downloads later, the prodigious sixth grader's choice for what to do next seems to be the only thing that fits into his age group's sensibilities: that's right, he spent his profits on an Xbox.

Sponsor

Last month the Manhattan Beach, California kid developer spoke about his burgeoning career and the technology gap separating young and old at TEDx conference about ideas worth spreading. At TEDxManhattan Beach, the young man took the microphone with confidence and smiles, speaking quite effectively and intelligently to an older crowd.

Here you can see him on stage, talking about how he created his apps with the iPhone SDK, some Python scripting and support from one of his teachers. He has amazing stage presence too.

"These days students usually know a little more than teachers with the technology," he said to a chorus of amused laughs. "Not many parents know how to make apps!"

Thomas, a self-taught programmer and student of Apple's "one to one" training service program, spoke for five minutes about the gap separating young and old, several times alluding to adults as the kids, and kids as adults in the world of tech.

"My first app was a unique fortune teller called Earth Fortune, that would display different colors of Earth depending on what your fortune was," Thomas said during his TED talk. "My favorite, most successful app is Bustin Jieber--a Justin Bieber whac-a-mole." (It costs a buck.)

In late 2010, he released the app using the premise of the Whac-A-Mole game. Spin-offs include Bustin Howie, and Bustin Piers (lampooning Howie Mandel and Piers Morgan). "I created it because a lot of people at school disliked Justin Bieber." He isn't alone in that sentiment, clearly.

So far he's made about $1,000 from the app, but the experience has made him a local celebrity. "A lot of kids these days like to play games, but now they want to make them. And it's difficult, because not many kids know where to go to find out how to make a program...Any student at my school can come and learn how to design an app. This is so I can share my experience with others."

With the help of his two younger brothers, Thomas lectures in front of a group of about 20 students at lunchtime. With the district part of the iPad pilot program, integrating iPads into the classroom and hour-long lunch lessons on the ins and outs of app creation, could the South Bay area of Los Angeles be the next blue chip incubator for tech talent? At least for the younger set.

"A big challenge is how should the iPads be used and what apps should we put on the iPads," he questioned at the end of his TED talk. "We're getting feedback from the teachers at the school to see what apps they like. When we design the app and we sell it, it will be free to local districts. And other districts that we sell to, all the money from that will be funneled to local ed foundations."

While the young technophile is working with a third-party company to make new apps, he said his next goal is to get into Android programming, continue his app club "and find other ways for students to share knowledge with others."

A very impressive 12-year old to be sure. And certainly the shape of things to come.

Discuss

Transfer Money Via NFC with the PayPal Android App

Dan Rowinski — Tue, 08 Nov 2011 12:20:00 PST

PayPal today issued an update to its Android app that will enable people to make payments to each other via near field communications enabled smartphones. This does not include consumer to merchant payments but rather is a widget geared towards making payments with friends or other PayPal using people that happen to have NFC on their devices.

PayPal has shunned NFC to this point in its mobile payments push. The company's stance has been "it will not be a hard thing for us to implement if we find that it gains popularity." Really, this new NFC sharing widget for Android does not change that stance at all. Peer-to-peer payments in PayPal are a service, not a business vertical. Essentially, this update for PayPal does not affect how the company will approach mobile payments.

Sponsor

PayPal does not make any money from peer-to-peer transactions. It is a feature that the company offers more or less because it can. Really, the best thing that peer-to-peer does for PayPal is give it insights into how people transfer money between each other through the data generated by each transaction.

The way PayPal makes it sound in the update to the Android app is that the new NFC feature is no different. It is a "hey, why not?" type of feature. Yet, it could be the set up for quite a bit more.

If PayPal tracks the data on peer-to-peer for trends (location, time of day, how much is being transferred, how far away are they) then the NFC rollout could be the first steps to tracking where, when and how to implement a possible NFC solution for smartphones.

There will be a wave of Android devices in 2012 that are NFC enabled. Right now there are only a handful with the Samsung Nexus S the most prominent of the bunch. This is a way for PayPal to have some type of NFC offering in the mix for when consumers get NFC devices in their hands and do not have much of a reason to actually use the feature.

We can imagine a dozen scenarios where independent merchants could use NFC payments. It comes back down to our well-worn farmer's market scenario - a farmer could use a NFC phone to accept PayPal payments from other PayPal Android users with NFC. While that seems cool, think of the limiting factors - both parties need NFC, Android, PayPal and a desire to do business. Finding two matching parties with those particular attributes right now is a niche within a niche.

By instituting the completely non-threatening peer-to-peer feature, PayPal sets itself up to widen the set of functionality down the line. For a company that is moving horizontally through the mobile payments sector, that shows surprising foresight.

Discuss

Steve Jobs Wins: Adobe to Give Up Mobile Flash for HTML5

Marshall Kirkpatrick — Tue, 08 Nov 2011 22:25:43 PST

Alt title: A Win for the Web.

Sources close to the news have told ZDNet reporter Jason Perlow tonight that Adobe will announce soon that it has given up on the development of mobile flash and will increase its investment in supporting HTML5. The company will say, according to an email published by Perlow, that it will encourage app developers to work with the cross-platform Adobe AIR platform to be distributed across mobile app stores, a caveat that could mean the news is less dramatic than it might seem. Rather than building with AIR for mobile, though, it seems likely that more developers will focus on HTML5 instead.

Feisty Twitter user Counternotions quotes Adobe's CEO from 2010 "Technology problems [w/ Flash] Mr. Jobs mentions...are 'really a smokescreen.'" Apple's refusal to go with the glitchy, gloppy proprietary protocol that performs poorly on Apple devices had to be a big part of what turned the tide.

Sponsor

Adobe prints giant piles of money from sales of its Flash authoring tools. (Point aptly critiqued below in comments, by the way. Flash on the desktop remains alive and relatively well.)

Update: Adobe published this statement today.

Apple CEO Jobs explained why he was opposed to the inclusion of support for Flash on Apple mobile devices in the Spring of 2010. Sarah Perez summarized his arguments as follows:

It's proprietary.

Most Web video plays on the iPhone/iPod Touch/iPad

Who needs Flash games? We have apps for that.

Flash has poor security.

Flash doesn't perform well on mobile devices.

Flash negatively affects battery life.

Flash was designed for PCs, not touchscreens.

Adobe contested those arguments of course, and Google was happy to support Flash on Android. At least one prominent benchmarking test found HTML5's performance to be comparable to Flash's. The European Union went so far as to consider forcing Apple to support Flash on the iPhone.

Adobe began offering an experimental Flash to HTML5 conversion technology this Spring.

Perlow, who broke the story tonight, has been a Senior Technology Editor at CBS's ZDNet since 2008 and was a Senior Editor at Linux Magazine for ten years prior.

The leaked news from Adobe says that the company will "continue to support the current Android and PlayBook configurations with critical bug fixes and security updates." That doesn't mean much for future configurations of those Operating Systems.

ZDNet's Microsoft specialist Mary Jo Foley reported earlier today that Silverlight may be slated for an imminent demise as well. Open standards FTW.

[Note: This post was written in a hurry but delayed until Flash and AIR apps on my Mac could be force quit. It's running much better now.]

Discuss

Facebook Restores the Old News Feed [UPDATED]

Alicia Eler — Wed, 09 Nov 2011 17:42:00 PST

Today Facebook announced an update to its much contested news feed. This new version builds upon the current hybrid news feed, and has some aspects of the old one. But instead of being able to toggle back-and-forth between "top news" and "recent news," users will see a "sort" button at the top which gives them the option to see highlighted stories first, or recent stories first.

"The highlighted stories are the ones which have the most likes or the ones which are featured to you," a Facebook spokesperson told ReadWriteWeb. "The most recent stories will be under those top stories. There will be a button where you can sort chronologically."

One thing that won't change in this news feed update is the larger-sized photos.

The update will rollout out tonight and continue over the coming weeks. See screengrabs after the jump.

Sponsor

Here's the second screenshot:

This is big news for Facebook users, who have complained relentlessly since the news feed switched over to hybrid.

Giving users the option to experience a news feed that's closer to the old one seems like a smart move Facebook.

The Facebook hybrid news feed has come under controversy since it launched. It has inspired more interaction than the old news feed, and the "new top story" section might be the reason. But Facebook users have demanded their old news feed - and it looks like they won.

Are you glad that the Facebook news feed is changing? Tell us what you think in the comments.

Discuss

Inimesed kasutavad üha vähem sularaha

erruudised@err.ee — Tue, 08 Nov 2011 23:38:00 PST

Sularaha roll eestimaalaste tegemistes on märgatavalt vähenenud ning üks põhjuseid on ilmselt ka üleminek eurole.

Loe edasi >

Eesti Loto veebileht oli mitu tundi maas

erruudised@err.ee — Wed, 09 Nov 2011 09:45:00 PST

Eesti Loto veebikeskkond, kust on võimalik osta lotopileteid ja kontrollida tulemusi, ei olnud täna õhtul ligi kolm tundi töökorras.

Loe edasi >

Eesti füüsikaõpetajad käisid CERNis teadmisi omandamas

erruudised@err.ee — Sun, 06 Nov 2011 21:09:00 PST

Tänu Šveitsis CERNis osakestekiirendiga töötavate Eesti teadlaste eestvedamisele sai 16 füüsikaõpetajat riigi kulul tutvuda koolivaheajal Euroopa moodsaima teaduskeskusega.

Loe edasi >

Maakera ei pea kõikide inimeste tarbimisunistuste täitumisele vastu

erruudised@err.ee — Sun, 06 Nov 2011 11:29:00 PST

Lõppeval nädalal sai inimesi maakeral seitse miljardit, kuid kui kõik tahaksid elada ja tarbida sama hästi kui meie, ei peaks maakera sellele tempole vastu, ütles bioloog Georg Aher.

Loe edasi >

Kriminaalse sisuga arvutimängud ei pruugi lapsele hästi mõjuda

erruudised@err.ee — Sun, 06 Nov 2011 12:38:00 PST

Arvutimängud on netipõlvkonna jaoks sama loomulikud, kui varasematele sugupõlvedele võsavahel indiaanlase ja kauboi mängimine, uue aja mängud avavad aga ukse mõttemaailma ja tegevuste juurde, millest enamik lapsevanemaid oma võsukesi meelsamini eemal hoiaksid.

Loe edasi >

There is No Silver Bullet In Software Development

(author unknown) — Sat, 05 Nov 2011 07:41:26 PDT

In my 30 years of programming at or near the leading edge of software technology I've seen a ton of ideas, tools, languages, processes and methodologies appear that each claimed to be the ultimate solution for improving how software is written.

Not one of them ever got beyond marginal success and many actually made things worse.

There isn't anything wrong about new ideas; each one represents a datapoint in an ever expanding search for a better way. Writing software is still hard and with each generation of technology expectations of the industry or the market often increases faster than the ability of programmers to keep up. So new ideas are necessary to find some way to get things done and stay one step ahead of the technology steamroller.

The assumption that there exists one idea that will revolutionize programming is what never seems to vanish despite decades of examples that prove there is no such thing. Even what amounts to the biggest change I can remember during my career, Object Orientation, which still dominates the programming language universe, isn't a panacea. Like so many other ideas it's only another tool in the toolbox, not the holy grail.

The one thing that unites all the great projects I have worked on over the years has always been the ability of the people involved. By people I mean everyone from managers to developers to architects to testers and often the customers as well. The best ones were able to communicate well, had both imagination to figure out how to solve tough problems and the discipline to know what to keep and what to reject, enough experience to know when a direction was going to work, the freedom to find and use the best tools or ideas to get the job done, and enough leadership to get the project complete. Sure it sounds pretty vague but during my lifetime of work nothing stands out but the people involved.

What has irked me most of my time is when people stand on a soapbox and say things like "if you don't use X then your code will suck" where X could be almost anything. I've heard this for so long it goes in one ear and out the other.

For every software development idea X that was invented at time Y people were still able to deliver excellent software long before Y.

For example I never heard of the term "unit testing" until the mid to late 90's. Yet me and the team I worked with on Trapeze, Persuasion and Deltagraph shipped 13 major releases of the 3 products (only 1 for Persuasion) with a nary a single unit test. The software was shipped on floppy disks (10 in the case of Deltagraph) where each release generally cost at least $10 to duplicate plus shipping. Deltagraph at its peak had 100,000 customers so the publishers entire profit for the year might be the eaten up by having to ship out a whole new set of disks if something major went wrong -- but not once did we have to do it. Today you can patch a bug online instantly (or not if you have to wait on the App Store review).

For Trapeze and Deltagraph the final ship decision was mine but the whole team knew and understood how to produce something that worked with no UML, no unit tests, no test first development, no design patterns, etc. and in C no less. Of course we weren't alone in that.

Would we have produced more quality or taken less time with all the modern ideas? Maybe, but it's always hard to compare different eras. Would doing things the way we worked back then work today? Tough to say as today's marketplace is so different. The point I am trying to make is that it's not the tool or the methodology or the language or the flavor of the month that matters but the people and how they go about getting the software done.

Over the years listening to software tool vendors was always a fun thing to do. Each one sold their products or system as if they were the final answer to all of life's programming problems. They never were of course but the fear of every programmer was that some manager would believe the hype and we'd all get stuck with something hopeless.

Managers and especially CIO/CTO types with no real technology background are the worst culprits when it comes to buying hype. Some vendors talks them up or they read an article and suddenly the entire company has to switch to something different. I'm sure every programmer has experienced this kind of insanity.

One CIO I worked for bought an expensive technology from a vendor that promised better enterprise development and then was asked to write a glowing report for their website about how it reduced our time to write software from 8 months to 5 weeks. Then that company sent some marketing people to interview the programmers and were shocked to find we didn't use it other than for one simple calculator, done only to keep the CIO at bay.

It's not that you can't improve things with better ideas, methodologies or tools; if not for improvements in how we write software theres no way we could keep up the demands of the modern world. It's just the expectation that something by itself is the perfect antidote to whatever ails your organization that is wrong.

I once spent a long time explaining Agile to the methodology team at the company I worked at (financial service firm) which operated more or less a waterfall. The team (yes there were actually 3 people on it) then went off and a few months later came up with the new methodology. Instead of something lean and agile they had taken the waterfall to a new extreme, basically 15 steps each with documents, meetings and schedule that defied understanding. The funny thing was the the 15th step was basically "write the software". Agile in concrete overshoes.

That's the flip side to new ideas - when people take the idea and recast it in the old idea's form and present it as new.

Clearly everyone wants to write software better and write better software. The issue is that the belief that any one thing will solve the problems is faulty but never seems to go away and probably never will. The real solution lies in the people involved and that sounds too fuzzy to be real so people try to find some technology solution to make things better.

As a final example I point to the original iPhone. Every phone manufacturer in the world had smart people. All of them had successful products and a long history in the industry. Yet Steve Jobs had an idea and a team he picked that he was confident could bring everything together from design to coding to manufacturing to marketing to make a phone with 3 buttons to change the entire industry. There was no single reason Apple did this (beyond Steve anyway) but the right people with the knowledge, experience and freedom to innovate and especially ability to communicate. The team made this happen, not any particular process or methodology or tool or language.

So keep your silver bullets handy for killing Werewolves and occasionally drinking a cold (crappy) beer. Just remember that in checking out something new in the programming universe you might find a better tool for your toolbox but you'll never throw the toolbox away completely and skip magically into nirvana.

Sõõrumaa ühendas K Grupi ja Pristise

erruudised@err.ee — Tue, 01 Nov 2011 00:23:00 PDT

Urmas Sõõrumaa lõi uue turvafirma USS, mis ühendab Pristise ja talle kuulunud K Grupi ning tõuseb G4S-i järel suuruselt teiseks turvaettevõtteks Eestis.

Loe edasi >

Dolphin, a 3rd Party Android Browser, Relayed URL Data

Soulskill — Sat, 29 Oct 2011 08:40:00 PDT

An anonymous reader sends this excerpt from AndroidPolice.com: "As it turns out, Dolphin HD, one of the top browsers the Android platform has to offer, sends pretty much every web page URL you visit, including those that start with https, to a remote server en.mywebzines.com, which belongs to the company. In fact, the WebZines feature was introduced only recently back in June with version 6.0, so it's safe to say this tracking started around the same time.'" The Dolphin team quickly responded with a blog post saying they did not store any of the data, and no browsing information was captured about users. They also rolled out a new version of the browser, 7.0.2, which fixed the issue.

Nokia Unveils OLED Phone You Control By Bending

timothy — Fri, 28 Oct 2011 22:33:00 PDT

jldailey618 writes "Nokia just unveiled an OLED smartphone that is controlled by flexing the device with both hands. By bending corners and pushing the sides inward and outward, the user can scroll, zoom, and select. 'Researchers would not discuss exactly how the processor behind the twisty screen functioned, but they did say that it would be compatible with most current operating systems.'" Reader jones_supa adds a link to The Inquirer (with video), which points out that the twist-based (rather than poke-based) interface means "you can do many basic functions such as scrolling, zooming and answering calls even while wearing mittens."

Meet Firefox's Built-In PDF Reader

timothy — Fri, 28 Oct 2011 15:36:00 PDT

An anonymous reader writes "Not long ago, Mozilla coders announced that they were starting to build PDF.js, a way to display Acrobat documents in the browser using pure web code. No longer will you have to fight with an external PDF plug-in in Firefox. Development on PDF.js has progressed to the point now where you can take an early peek at it. Huzzah!"

Developers: Your Google Maps API Free Riding Days Are Over

Marshall Kirkpatrick — Wed, 26 Oct 2011 22:22:05 PDT

Months after warning developers it would happen, the Google Developer team announced tonight that the era of unlimited Google Maps usage for free is officially over. Developers whose apps load more than 25,000 basic maps or 2500 stylized maps per day will have to cough up some cash.

An era has ended for the first API that really made mashups mainstream, most famously via housingmaps.com, a mashup of Craigslist rental search results and Google Maps. Unlimited access may no longer be available for free, but some observers say it's a good move for the developer ecosystem. "For some developers this can clearly be an issue but overall it's healthy for the ecosystem," John Musser of API watch-dog site Programmable Web told us tonight. "Services need to be sustainable with business models that work for both sides."

Sponsor

Launched in June of 2005, the Google Maps API is the archetypal API, or Application Programming Interface. A number of other map APIs now allow data to be displayed on a map, though, and thousands of other APIs allow data to be read from or written to other websites and services.

The free vs commercial nature of Google APIs and the Maps API in particular have always been a little unclear.

"Given the value these APIs give and the cost of running them," says independent Australian developer Daniel Treadwell in words echoed by many people, "I think charging for it isn't a problem at all. The last thing anyone wants is for it to be retired like some others have been."

This Spring, there was a massacre of free Google APIs that got slated for shut down so the company could focus on other priorities. Weeks later, Google changed its mind about its Translate API in particular, announcing it would develop a paid version that developers dependent on it could rely on.

It's extremely unlikely that the Maps API would ever disappear altogether, but even if it did there are already viable alternatives including Open Street Map and MapQuest. Other up-and-coming options include DevelopmentSeed and TileMill.

So far, though, many developers appear satisfied with the way Google is handling this transition tonight. (Except some dissenters on my Google Plus thread, which is great to see. Keep it up, dissenters!) That's good for the future of location-based application development and innovation. Google Maps is a living, breathing, changing, incredibly valuable resource. If you wrote an app that has got enough traction that you're cranking on that API past a certain limit, paying something for it certainly seems fair.

Paul Rademacher, the creator of HousingMaps.com, had this to say in response to the announcement:

My concern would be that individual and small-team developers (who have fueled the geo explosion) not be scared away by this change. 25,000 maps per day is actually quite high, and should cover the long tail of API sites. It takes a lot of press or very healthy sustained traffic to reach that number. One main question developers will have is "what happens if my site suddenly hits the front page of X and gets huge traffic?" That should be ok according to the Maps API FAQ, so long as it's a short-term spike. I expect the vast majority of sites won't be affected at all by the new usage limit, some very small number of very large sites will be affected, and for those in between: talk to Google API Premier team and figure something out. To the small geo developers: please keep coding!!

Discuss

The Ranger's shared items in Google Reader

Nokia toob suvel turule oma tahvelarvuti

Viirus levitab Facebookis pornot ja vägivaldseid pilte

Swedbank tahab netipanga serverid Rootsi viia, eksperdid näevad ohtu

Your users don't care if you use Web Sockets

Related Links

Solving the Shakespeare Million Monkeys Problem in Real-time with Parallelism and SignalR

Even 12 Year Olds Can Write Their Own Justin Bieber Apps

Transfer Money Via NFC with the PayPal Android App

Steve Jobs Wins: Adobe to Give Up Mobile Flash for HTML5

Facebook Restores the Old News Feed [UPDATED]

Inimesed kasutavad üha vähem sularaha

Eesti Loto veebileht oli mitu tundi maas

Eesti füüsikaõpetajad käisid CERNis teadmisi omandamas

Maakera ei pea kõikide inimeste tarbimisunistuste täitumisele vastu

Kriminaalse sisuga arvutimängud ei pruugi lapsele hästi mõjuda

There is No Silver Bullet In Software Development

Sõõrumaa ühendas K Grupi ja Pristise

Dolphin, a 3rd Party Android Browser, Relayed URL Data

Nokia Unveils OLED Phone You Control By Bending

Meet Firefox's Built-In PDF Reader

Developers: Your Google Maps API Free Riding Days Are Over