Objects as Actors : Should distribution transparency be embedded into a language design ?

Debasish Ghosh has written an interesting post : Objects as Actors. A very nice post touching upon the frequent debate of what abstraction should be included a piece of software and how should it be modeled. Even though readers and users often express their own views and experiences, it often boils down to the intent of the author and the specific problems he chose to address.

Debasish refers to the point that in Scala Actors are implemented as a library even as Objects continue to be one of the building blocks of the language.

The way I look at it, this is mostly a decision of the philosophy of the language design. Scala is targetted to be a general purpose programming language, where concurrency and distribution are not the central concerns to address as part of the core language design.

…

The entire actor model has hence been implemented as a library that integrates seamlessly with the rest of Scala’s core object/functional engineering. This is a design decision which the language designers did take upfront – hence objects in Scala, by default, bind to local invocation semantics, that enable it to take advantage of all the optimizations and efficiencies of being collocated in the same process.

Within the context of erlang he goes on to add

Hence languages like Erlang, which address the concerns of concurrency and distribution as part of the core, have decided to implement actors as their basic building block of abstractions. This was done with the vision that the Erlang programming style will be based on simple primitives of process spawning and message passing, both of which implemented as low overhead primitives in the virtual machine.

…

Erlang allows you to write programs that will run without any change in a regular non-distributed Erlang session, on two different Erlang nodes running on the same computer and as well on Erlang nodes running on two physically separated computers either in the same LAN or over the internet. It can do this, because the language designers decided to map the concurrency model naturally to distributed deployments extending the actor model beyond VM boundaries.

The general conclusion is that its a matter of the intent of the author and the problems he chose to address.

Comprehension consistency at last in Python 3.0!

Comprehension consistency at last in Python 3.0!.

Nice example of how comprehensions in Python 3.0 seem a lot more intuitive.

Earlier in Python 2.5 :

Python 2.5.2 (r252:60911, Nov 14 2008, 19:46:32)
[GCC 4.3.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>>
>>> dict((n, n*n) for n in range(5))
{0: 0, 1: 1, 2: 4, 3: 9, 4: 16}

New in Python 3.0

Python 3.0 (r30:67503, Dec  4 2008, 10:23:44)
[GCC 4.3.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>>
>>> [ n*n for n in range(5) ]
[0, 1, 4, 9, 16]
>>>
>>> { n*n for n in range(5) }
{0, 1, 4, 16, 9}
>>>
>>> { n: n*n for n in range(5) }
{0: 0, 1: 1, 2: 4, 3: 9, 4: 16}

Free Public WiFi SSID is Not Virus ?

Free Public WiFi SSID at WLAN Book.com.

I was told this stuff is a virus so I avoided it. Apparently it isn’t. However the network SSID does seem to have some viral characteristics. In summary :

In reality, this SSID is just one of many viral SSIDs that exist anywhere people are with laptops (almost always Microsoft Windows based laptops). In almost all cases this SSID is not a real WiFi hotspot access point but someone else’s laptop in Ad-Hoc mode advertising this SSID

The answer to why this SSID seems to be everywhere can be blamed on Microsoft, more specifically a Windows feature called Wireless Auto Configuration (aka Wireless Zero Configuration).

One of the suggestions the article makes :

Can this viral SSID be stopped?
Yes, but others exist like linksys, hpsetup, tmobile, default. Any SSID that tends be the default for consumer grade access points and computers tends to become viral ad hoc SSIDs. An easy way to reduce the risk of connecting to these SSIDs is to configure Wireless Auto Configuration to only connect to access points (infrastructure networks).

Seems interesting how in a suspicious world even innocuous mistakes get looked at suspiciously. Also apparently seems a good example of law of unintended consequences which again software / usability designers need to be conscious of.

Any easier and funnier way to explain SQL injection

97 Things Every Software Architect Should Know – The Book [97 Things] : Near-Time

Nice collection of blog posts dealing with architecture.

97 Things Every Software Architect Should Know – The Book [97 Things] : Near-Time.

Is documentation more important or answers ?

When people are looking for documentation are they “really” looking for documentation ? This article argues that what people are really looking for is “answers”. So long as you are able to get them, documentation per se may not be the criteria.

James Shore: The Documentation Myth.

Chrome is a security nightmare, indexes your bank accounts

TG Daily – Chrome is a security nightmare, indexes your bank accounts.

This is an interesting side effect of security issues arising out of perhaps indexing that actually works “too well”.

Inside Chrome: The Secret Project to Crush IE and Remake the Web

Inside Chrome: The Secret Project to Crush IE and Remake the Web.

Nice story about the happenings behind the scenes leading to google chrome.

How To Demo Your Startup (Part Two)

How To Demo Your Startup (Part Two).

Agile or Lean ?

So as you can see, lean and agile are deeply intertwined in the software world. You can’t really talk about them being alternatives, if you are doing agile you are doing lean and vice-versa. Agile was always meant as a very broad concept, a core set of values and principles that was shared by processes that look superficially different. You don’t do agile or lean you do agile and lean. The only question is how explicitly you use ideas that draw directly from lean manufacturing.

MF Bliki: AgileVersusLean.

Startup Lessons Learned — Take it with a grain of salt

Another startup lessons learnt essay.

Untitled – Startup Lessons Learned — Take it with a grain of salt.

Summary (for a much more detailed article, follow the link) :

You can’t afford to have a religion.

Communication

Agile development, actually.

Distributed Development isn’t such a great idea…

Don’t file expensive patents when you are pre-seed.

Attention to Detail

Release Early, Release Often

Fire Fast

Highs and Lows — Never give up

Don’t let your start-up define you

Most commonly used blog post title words on ycombinator

As per hacker news .. the 100 most commonly used blog post title words are :

google startup web facebook yc new ask why social app business microsoft |2.0| software world iphone video apple idea site user free vc online internet open search network year news mobile like best hacker make way good |10| ruby application time future ad top first language programming use code service vs |2007| now design rails lisp launches yahoo amazon developer over million data javascript life thing interview music us company source founder using tech python people game big work great tip most know blog job book programmer entrepreneur problem platform next website need computer better |2008| money where project own

Hacker News News.

How to improve your sites credibility – suggestions from the web credibility project – stanford university

Nice set of points for enhancing your sites credibility. Reproducing the bullet points below, the details are on the link referred to.

The Web Credibility Project: Guidelines – Stanford University.

• Make it easy to verify the accuracy of the information on your site.
• Show that there’s a real organization behind your site.
• Highlight the expertise in your organization and in the content and services you provide.
• Show that honest and trustworthy people stand behind your site.
• Make it easy to contact you.
• Design your site so it looks professional (or is appropriate for your purpose).
• Make your site easy to use — and useful.
• Update your site’s content often (at least show it’s been reviewed recently).
• Use restraint with any promotional content (e.g., ads, offers).
• Avoid errors of all types, no matter how small they seem.

Introducing Ubiquity

Ubiquity for Firefox from Aza Raskin on Vimeo.

Mozilla Labs » Blog Archive » Introducing Ubiquity.

Seems v. promising firefox extension .. allows users to do their own mashups from the browser.

Seems to have a very geeky interface – keyboard command to launch ubiquity and text commands to be entered using keyboard to use it. But definitely seems quite powerful.

Search experiments, large and small

Nice post listing some of google’s experiments in sometimes small and seemingly trivial aspects of their search.

Official Google Blog: Search experiments, large and small.

Experimentation is a very powerful tool, and we use it very widely to test potential changes to search. At any given time, we run anywhere from 50 to 200 experiments on Google sites all over the world.

Cheaper Talent Hypothesis

MF Bliki: CheaperTalentHypothesis.

Martin Fowler’s commentary on why cheaper talent is more expensive !

Naturally better programmers cost more, either as full-time hires or in contracting. But the interesting question is, despite this, are more expensive programmers actually cheaper?

…

If the cost premium for a more productive developer is less than the higher productivity of that developer, then it’s cheaper to hire the more expensive developer. The cheaper talent hypothesis is that the cost premium is indeed less, and thus it’s cheaper to hire more productive developers even if they are more expensive.

…

The trouble is that that assumption assumes productivity scales linearly with team size, which again observation indicates isn’t the case. Software development depends very much on communication between team members. The biggest issue on software teams is making sure everyone understands what everyone else is doing. As a result productivity scales a good bit less than linearly with team size. As usual we have no clear measure, but I’m inclined to guess at it being closer to the square root. If we use my evidence-free guess as the basis then to get double the productivity we need to quadruple the team size. So our average talent team needs to have forty people to match our ten talented people – at which point it costs twice as much.

…

Agile development further accelerates this effect. A talented team has a faster cycle time than an average team. This allows the full team to explore options faster: building, evaluating, optimizing. This accelerates producing better software, thus generating higher value. This compounds the time-to-market effect. (And it’s natural to assume that a talented team is more likely to produce better software in any case.)

Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too.

…

So I understand the situation but don’t accept it. I believe that if the software industry is to fulfill its potential it needs to recognize the cheaper talent hypothesis and close the gap between high productivity and higher compensation.

Bell Labs Kills Fundamental Physics Research

Bell Labs Kills Fundamental Physics Research | Gadget Lab from Wired.com.

Sad .. but probably necessary under the current economic scenario.

After six Nobel Prizes, the invention of the transistor, laser and countless contributions to computer science and technology, it is the end of the road for Bell Labs’ fundamental physics research lab.

…

Bell Labs was one of the last bastions of basic research within the corporate world, which over the past several decades has largely focused its R&D efforts on applied research — areas of study with more immediate prospects of paying off.

Without internally funded basic research, fundamental research has instead come to rely on academic and government-funded laboratories to do kind of long-term projects without immediate and obvious payback that Bell Labs used to historically do, says Lubell.

…

For Bell Labs, yet another chapter in its storied history of comes to a close taking the once iconic institution closer to being just another research arm of a major corporation.

Unit testing is doomed when it’s an elephant

The Disco Blog » Blog Archive » Unit testing is doomed when it’s an elephant.

Very nice commentary on why it is difficult to take up automated unit testing in many shops (with a slight focus on Java shops)

The question remains, however; is unit testing doomed? The answer to this question, of course, depends on your point of view, baby– or more precisely, what kind of development you are currently performing. For, as Andrew noted, if you are currently practicing Agile development, where unit testing has taken a strong hold and where “developers write hundreds of small tests for exercising their own code” the answer to the former question is a resounding no!

…

The reality of the Java market though, is that there is an entire throng of people who didn’t (or couldn’t) jump on the JUnit bandwagon all those years ago– this crowd is largely maintaining enterprise applications that are, simply put, incredibly hard to unit test, man. In these organizations, I have found that, more often than not, this is where the battle for tried and true unit testing is being lost.

…

Think about it for a second– unit testing is the elephant in the room. You’ve just been asked to eat it. But you can’t just take a steak knife and fork and start eating– the elephant is still alive looking right at you. No, you’ve got to first kill it, cut it up, cook it, etc. No wonder few people eat the elephant. Burger King is around the corner! No wonder unit testing often times seems doomed. We have a QA team that finds bugs!

Indubitably, these development teams are forced to rely on late cycle testing or at best, in the short term, can of course build up a hip suite of higher level tests. As a matter of fact, this is probably the best place to start! Can’t isolate that Account object for unit testing? No problem, bite the bullet and code an integration test– just make sure you realize you’ve got to handle the myriad dependencies associated with that business transaction (think a properly seeded database, etc).

…

As I said, if unit testing, as it is defined within the context of TDD, is an elephant for you and your organization, then it

is likely to remain a niche solution, found at organizations that really understand its value and progressively adopted by sites that can no longer stand the long debug cycles.

The answer to most questions depends on your point of view– if you are working on a team that has embraced agile principles, unit testing is alive and well. It’s a healthy practice that when questioned brings extreme consternation to those who’ve drank the Kool-Aid.

If you find yourself working on a legacy code base, your answer might be somewhat different– indeed, unit testing in these cases is not as easy as downloading JUnit and coding away. It’s a sizable elephant that a culture has to collectively figure out how to eat. And that takes time, commitment, and a lot of discipline. If you can’t get a handle on those three aspects, then yes, unit testing is doomed. Can you dig it, man?

Simple Update Protocol: Fetch updates from feeds faster

SUP (Simple Update Protocol) is a simple and compact “ping feed” that web services can produce in order to alert the consumers of their feeds when a feed has been updated. This reduces update latency and improves efficiency by eliminating the need for frequent polling.

FriendFeed Blog: Simple Update Protocol: Fetch updates from feeds faster.

Enterprise Java Community: Building a Scalable Enterprise Applications Using Asynchronous IO and SEDA Model

Enterprise Java Community: Building a Scalable Enterprise Applications Using Asynchronous IO and SEDA Model.

A nice article providing an overview of SEDA architecture and showing an example of building an application using the same along with tomcat and mule, and benchmark results thereof

• Categories

  • Interesting

• Tags

  agile apple architecture behaviour browser business community digg domain economics engineering google hr humour india intelligence interviews iphone java leadership learning management misc mobile new tech outsourcing people programming project management quotes recruitment requirements scalability security site-design software development startups support talent tdd team leading testing usability utility web