jQuery Pumpkin

in JQuery Blog, Tue, 28 Oct 2008 19:52:34 GMT

jQuery Halloween Pumpkin

Created by jQuery user Christopher Pickert (of BigFishGames.com), he writes:

"Since Halloween is the perfect time to celebrate the black arts of web development, I carved a special jQuery pumpkin last night. I hope you enjoy it.

Our QA person said that he found a bug in the code, but I explained that it was because of the candle."

He continues:

I did carve that - it’s not photoshop. On an impulse I bought a little $7 battery-operated pumpkin saw at the grocery store, and it’s great because you can do small details more easily. So actually the hard part was drawing the characters first and getting them the right size.

Great work Christopher!

View: jQuery Pumpkin - More entries from JQuery Blog, Web Development

Three steps for turning a tier-based/Spring-application into dynamically scalable services (video)

in High Scalability, Tue, 28 Oct 2008 10:16:25 GMT

Summary
In this presentation, a three steps approach for turning your existing stateful tier-based/Spring-application into a dynamically scalable services application using OpenSpaces is demonstrated. The existing programming model is kept the same while focusing on abstracting and replacing the underlying implementations of the middleware stack in a way that will fit the scale-out model.

Bio
Nati Shalom is the CTO and Founder of GigaSpaces and responsible for the technology roadmap. He has 10 years of experience with distributed technology and architecture namely CORBA, Jini, J2EE, Grid and SOA. Nati is the Head of the Israeli Grid consortium and an evangelist of Space Based Architecture and Data Grid patterns. Blog: Gigaspaces Blog

Read the rest of the article here on InfoQ.

Notify.me Architecture - Synchronicity Kills

in High Scalability, Mon, 27 Oct 2008 14:05:53 GMT

What's cool about starting a new project is you finally have a chance to do it right. You of course eventually mess everything up in your own way, but for that one moment the world has a perfect order, a rightness that feels satisfying and good. Arne Claassen, the CTO of notify.me, a brand new real time notification delivery service, is in this honeymoon period now.

Arne has been gracious enough to share with us his philosophy of how to build a notification service. I think you'll find it fascinating because Arne goes into a lot of useful detail about how his system works.

His main design philosophy is to minimize the bottlenecks that form around synchronous access, that is when some resource is requested and the requestor ties up more resources, waiting for a response. If the requested resource can’t be delivered in a timely manner, more and more requests pile up until the server can’t accept any new ones. Nobody gets what they want and you have an outage. Breaking synchronous operations into asynchronous operations by separating request and response into separate message passing actions, stops the resource overload. Instead of a system going down from too many parallel requests, it can works its way through a backlog of requests as fast as it can. And in most cases the request/response cycles are so fast that they appear like a linear sequence of events.

Notify.me is taking the innovative and risky strategy of using ejabberd, an XMPP based system, as their internal messaging and routing layer. Will Erlang and Mnesia (Erlang's database) be able to keep up with traffic and keep low latencies as traffic scales? It will be interesting to find out.

If you are interested in notify.me they've kindly offered 500 beta accounts for HS readers: http://notify.me/user/account/create/highscale

Who are you?

My name is Arne Claassen, the CTO of notify.me. I've been working on highly scalable web
based applications and services for the past decade. These sites have employed various
combinations of traditional scaling techniques such as server farms, caching, content pregeneration
and highly available databases using replication and clustering. All of these
techniques are ways to mitigate scarce resources (generally the database) being in
contention by many users. Knowing the benefits and pitfalls of these techniques, it has
become my focus to architect systems that circumvent scare resource scenarios.

What is notify.me, why did you make it, and why is it a good thing?

read more

Should you use a SAN to scale your architecture?

in High Scalability, Sun, 26 Oct 2008 15:52:22 GMT

This is a question everyone must struggle with when building out their datacenter. Storage choices are always the ones I have the least confidence in. David Marks in his blog You Can Change It Later! asks the question Should I get a SAN to scale my site architecture? and answers no. A better solution is to use commodity hardware, directly attach storage on servers, and partition across servers to scale and for greater availability.

David's reasoning is interesting:

  • A SAN creates a SPOF (single point of failure) that is dependent on a vendor to fly and fix when there's a problem. This can lead to long down times during this outage you have no access to your data at all.
  • Using easily available commodity hardware minimizes risks to your company, it's not just about saving money. Zooming over to Fry's to buy emergency equipment provides the kind of agility startups need in order to respond quickly to ever changing situations.
  • It's hard to beat the power and flexibility (backups, easy to add storage, mirroring, etc) of a good SAN, but Mark makes a good case.

    11 Secrets of a Cloud Scale Consultant That They Dont' Want You to Know

    in High Scalability, Fri, 24 Oct 2008 14:11:17 GMT

    OK, there is no "they" and "they" wouldn't care if you knew anyway. After all, this isn't a blog about really important stuff like investing, acne cures, or cheap natural cleansing products.

    But the secrets are real. Super cloud scaling consultant Kent Langley has put together a comprehensive checklist to consider when developing for the cloud:

  • ORM for Data Partitioning and Query Splitting
  • Monitoring process, resources, and uptime
  • Performance Testing and Capacity Planning
  • Static vs. Dynamic Content splitting / CDN
  • Bundling and Compressing JS and CSS
  • Logging
  • Pragmatic Caching
  • Functional Decomposition
  • Deployment
  • Asynchronous Practices
  • Make sure your application processes are as lean as possible
  • Please follow the link to Kent's post for a full explanation. Good helpful stuff.

    Related Articles


  • Joyent - Cloud Computing Built on Accelerators by Kent Langley
  • dojofoundation.org Is Up!

    by Alex Russell in Continuing Intermittent Incoherency, Wed, 22 Oct 2008 22:26:08 GMT

    My warmest thanks and a hearty “congrats!” to the Uxebu crew and Dylan for getting the new dojofoundation.org site up and running:

    The new site is important for a couple of reasons. First, it’s a good step in the direction of working to make clear that Dojo-the-javascript-toolkit and Dojo-the-foundation are completely separate entities with different goals and different leadership. The Foundation will take any and all projects that want a good home and are willing to meet the basic criteria that let others trust the code and process behind Foundation projects. It’s been weird that most of the documentation about Foundation policies and procedures has lived on the Toolkit site for so long, and having them be totally separate should help clarify.

    Secondly, the Foundation site helps show off the projects which aren’t the toolkit. The Foundation has more than doubled in size in the last year (in terms of projects), and looks set to continue that expansion. That the Toolkit project gets the most attention has been a long-term irritant to nearly everyone involved, and it’s my hope that the Foundation site will help to fix that.

    Lastly, the Foundation site is beautiful. Built with the Toolkit and Dojango, the site is a great showcase for the kinds of things that are easy to build with Foundation-sponsored technologies. Nice work everyone!

    Scalability Best Practices: Lessons from eBay

    in High Scalability, Wed, 22 Oct 2008 20:42:17 GMT

    At eBay, one of the primary architectural forces we contend with every day is scalability. It colors and drives every architectural and design decision we make. With hundreds of millions of users worldwide, over two billion page views a day, and petabytes of data in our systems, this is not a choice - it is a necessity.

    In a scalable architecture, resource usage should increase linearly (or better) with load, where load may be measured in user traffic, data volume, etc. Where performance is about the resource usage associated with a single unit of work, scalability is about how resource usage changes as units of work grow in number or size. Said another way, scalability is the shape of the price-performance curve, as opposed to its value at one point in that curve.

    There are many facets to scalability - transactional, operational, development effort. In this article, I will outline several of the key best practices we have learned over time to scale the transactional throughput of a web-based system. Most of these best practices will be familiar to you. Some may not. All come from the collective experience of the people who develop and operate the eBay site.

    Read the rest of the article on InfoQ.

    Server load balancing architectures, Part 2: Application-level load balancing

    in High Scalability, Wed, 22 Oct 2008 20:38:06 GMT

    The transport-level server load balancing architectures described in the first half of this article are more than adequate for many Web sites, but more complex and dynamic sites can't depend on them. Applications that rely on cache or session data must be able to handle a sequence of requests from the same client accurately and efficiently, without failing. In this follow up to his introduction to server load balancing, Gregor Roth discusses various application-level load balancing architectures, helping you decide which one will best meet the business requirements of your Web site.

    The first half of this article describes transport-level server load balancing solutions, such as TCP/IP-based load balancers, and analyzes their benefits and disadvantages. Load balancing on the TCP/IP level spreads incoming TCP connections over the real servers in a server farm. It is sufficient in most cases, especially for static Web sites. However, support for dynamic Web sites often requires higher-level load balancing techniques. For instance, if the server-side application must deal with caching or application session data, effective support for client affinity becomes an important consideration.

    Here in Part 2, I'll discuss techniques for implementing server load balancing at the application level to address the needs of many dynamic Web sites.

    Read the rest of the article on JavaWorld.

    Server load balancing architectures, Part 1: Transport-level load balancing

    in High Scalability, Wed, 22 Oct 2008 20:34:35 GMT

    Server farms achieve high scalability and high availability through server load balancing, a technique that makes the server farm appear to clients as a single server. In this two-part article, Gregor Roth explores server load balancing architectures, with a focus on open source solutions. Part 1 covers server load balancing basics and discusses the pros and cons of transport-level server load balancing.

    The barrier to entry for many Internet companies is low. Anyone with a good idea can develop a small application, purchase a domain name, and set up a few PC-based servers to handle incoming traffic. The initial investment is small, so the start-up risk is minimal. But a successful low-cost infrastructure can become a serious problem quickly. A single server that handles all the incoming requests may not have the capacity to handle high traffic volumes once the business becomes popular. In such a situations companies often start to scale up: they upgrade the existing infrastructure by buying a larger box with more processors or add more memory to run the applications.

    Read the rest of the article on JavaWorld.

    EVE Online Architecture

    in High Scalability, Wed, 22 Oct 2008 18:15:09 GMT

    EVE Online is "The World's Largest Game Universe", a massively multiplayer online game (MMO) made by CCP. EVE Online's Architecture is unusual for a MMOG because it doesn't divide the player load among different servers or shards. Instead, the same cluster handles the entire EVE universe. It is an interesting to compare this with the Architecture of the Second Life Grid. How do they manage to scale?

    Information Sources

    Platform

    • Stackless Python used for both server and client game logic. It allows programmers to reap the benefits of thread-based programming without the performance and complexity problems associated with conventional threads.
    • SQL Server
    • Blade servers with SSDs for high IOPS
    • Plans to use Infiniband interconnects for low latency networking
    • What's Inside?

      The Stats

      • Founded in 1997
      • ~300K active users
      • Up to 40K concurrent users
      • Battles involving 1000 ships
      • 250M transactions per day

      read more

    Josh asks the CSS Guy about row locking with jQuery

    in Ask the CSS Guy, Wed, 22 Oct 2008 14:49:22 GMT

    With regards to this article, Josh writes:

    "Would it be possible for you to recreate this with jQuery and see how many lines of JS you can save in the process?"

    Yes!

    This is a direct jQuery replacement of this particular example.

    The jQuery

    I ditched all the home-grown functions, linked out to the jQuery-latest.js, then wrote the following bits:

    $(document).ready(function() {
      $('.pickme tbody tr:odd').addClass('odd');
      $('.pickme tbody tr').hover(
        function() { $(this).addClass('highlight'); },
        function() { $(this).removeClass('highlight'); }
      ).click( function() {
        $('.selected').removeClass('selected');
        $(this).addClass('selected').find('input').attr('checked','checked');
      });
    });

    In English, this says:

    1. When the page has finished loading the DOM...
    2. add a class of 'odd' to every other row in the table...
    3. then assign a hover behavior that consists of:
    4. adding a class of 'highlight' to the row when hovered into...
    5. and removing the class of 'highlight' when hovered away.
    6. When any row is clicked...
    7. remove the class of 'selected' from any other row that happens to have it...
    8. then add class of 'selected' to the current row, while also checking it's radio button.

    This is much shorter and easier to write for than the previous example. Compare the javascript written in the source code on the previous version to the jQuery version.

    The usual warnings for using libraries still apply. If it's a single effect on your site, it is likely best and more concise to write out your functions from scratch, but if you are already using jQuery (or any other library) on your site, take advantage of it. Also, just because it's easy doesn't make it right - give consideration to whether a behavior should be applied at all.

    Alternatives to Google App Engine

    in High Scalability, Mon, 20 Oct 2008 07:22:36 GMT

    One particularly interesting EC2 third party provider is GigaSpaces with their XAP platform that provides in memory transactions backed up to a database. The in memory transactions appear to scale linearly across machines thus providing a distributed in-memory datastore that gets backed up to persistent storage.

    Fonts, Podcast, Performance

    by John Resig in eJohn, Sat, 18 Oct 2008 07:23:07 GMT

    Three tidbits from this week:

    I published an article on W3C Web Fonts at Ars Technica the other day.

    I did another Open Web Podcast this week, this time with Ryan Steward of Adobe.

    On Thursday I gave a talk at the Web Experience Forum here in Boston talking about Performance Improvements that are coming in new browsers.


    Why Are We Even Having This Discussion?

    by Alex Russell in Continuing Intermittent Incoherency, Fri, 17 Oct 2008 21:47:43 GMT

    Content after the jump due to the public policy nature of the post.

    Here we go again.

    Every four years we go into the partisan spasms of a heat-not-light [dis]enfranchisement “debate”. What’s perpetually lost is any coherent discussion of the causes of the debate. As with gerrymandering, the causes are structural and neither party feels it would serve them to effectively deal with the situation at it’s roots. Not because solving the problem wouldn’t be better for everyone (in both cases, it objectively would), but because it would change the game, and our 2-party system is nothing if not over-specialized to the current rules of the game. In this sense, both redistricting reform (killing gerrymandering dead) and automatic voter registration systems cause the old rules to lose their hold, instantly changing the calculus of holding on to power. Automatic registration via so-called “motor-voter” laws, registration with passport applications, automatic updates with change-of-address on US mail, and other sensible policies are opposed by partisans of both parties because they have the potential to allow discontent to cause large swings in electorate behavior. Today, between the systematic disenfranchisement caused by requiring citizens to register to vote and the effective gerrymandering-based dampening of popular will, enormous changes in likely voter feelings about the direction of the country (or, less often, a locality/district) are required to break an incumbent’s grip on power. As an example, the “right-track/wrong-track” polling numbers in 2006 said that nearly 70% of Americans thought the country was on the wrong track. That feeling swept the Democrats into a razor-thin congressional majority (which the Republicans have been filibustering to death ever since), but in a 2:1 year, wouldn’t you expect a similar landslide in Congress? Perhaps not in the Senate where fewer seats are up for a vote as a structural hedge against change, but certainly we should have collectively turned enough of the bums out to make the remaining ones fear for their jobs. As it happened, in a race with 33 seats up for discussion (15 held by Republicans), only 5 of the bums lost their seats. Now compare that to the most recent pre-Bush period of comparable “right-track/wrong-track” numbers: the Republican revolution” of ‘94. On that basis it becomes evident that a shift in power half-again as large – based on the same “market fundamentals” – was at least justified. 8 seats changed hands in ‘94 vs. 5 in ‘06. The difference? A census and therefore a chance for many states to gerry….er…redistrict. The calcifying power of…um…power worked its magic 2 years ago and the Senate is deadlocked as a result.

    All of these effects cause fewer parts of the country to be competitive. If you support competition in markets (as I do), then there’s no higher calling than supporting a competitive marketplace for ideas, and both parties are doing their best to stifle the pricing function of our public policy market. No wonder then that Republicans think they can steal (or at least dispute) an election by challenging voters in Ohio, despite many discredited attempts in the past to find large-scale vote fraud. Eight years of intense Republican scrutiny into the non-issue has utterly failed to turn up any massive conspiracy or even credible small-scale fraud. Remember, pressuring US AG’s to prosecute thin or non-existent voter fraud cases – then firing them when they couldn’t find any and/or wouldn’t make them up – is what got Alberto Gonzalez hauled before congress for months on end, eventually leading to his disgraced resignation and continuing questions as to the impartiality of the DOJ. This isn’t a winner of an issue for the GOP, but it sure is an effective way to try to keep the under-informed from coming to the polls and having their votes counted. And they know it. Scare-tactics and fear-mongering as [keep|get]-out-the-vote strategy. Democrats, naturally, feel that their on-the-ground vote registration in targeted areas can be an effective weapon in distorting the outcome.

    Either way, it’s shameful.

    The Democratic approach is perhaps less reprehensible since the folks who are registered can vote however they please, but there’s no denying the attempt at demographic distortion. But why should citizens need to register as a separate process from establishing residency, getting mail, or a driver’s license anyway? And why isn’t same-day registration the law of the land? If Wyoming can do it, why not New York and California?

    Fundamentally, all the objections to broad enfranchisement end in a large-scale IT problem…but not a particularly hard one. What I’m not hearing from nearly anyone is a recognition that this shouldn’t be a debate that happens in a functioning democracy. That we have it on a quadrennial basis is simply an embarrassing acknowledgment that our democracy is not functioning.

    If McCain really wants to put “country first” and be a maverick, he’d be bringing this up as an urgent topic of national debate. It would certainly be better than the sleazy robo-call effort his campaign is now investing in. And if Obama wanted to build real credibility with Americans about his willingness to effect real change, shouldn’t he start here? Certainly it’s a better use of the national discourse than helping McCain draw unwarranted (and likely un-wanted) attention to a plumber. And where the hell is the 4th Estate when we need them?

    Oh, right. Camped out on some plumber’s lawn.

    Luckily, I happen to live in California where the Governor (who I disagree with more than not) has put redistricting reform on the ballot in the form of Prop. 11. I’ll be voting “yes” on 11, if only to make it that less likely that 4 years from now we’ll have to have this “discussion” again.

    A High Performance Memory Database for Web Application Caches

    in High Scalability, Fri, 17 Oct 2008 15:22:29 GMT

    Abstract—This paper presents the architecture and
    characteristics of a memory database intended to be used as a
    cache engine for web applications. Primary goals of this database
    are speed and efficiency while running on SMP systems with
    several CPU cores (four and more). A secondary goal is the
    support for simple metadata structures associated with cached
    data that can aid in efficient use of the cache. Due to these goals,
    some data structures and algorithms normally associated with
    this field of computing needed to be adapted to the new
    environment.

     

    Web Development

    Web development is a broad term that incorporates all areas of developing a web site for the World Wide Web. This can include e-commerce business development, web design, web content development, client-side/server-side coding, and web server configuration. However, among web professionals, "web development" usually refers only to the non-design aspects of building Web sites, e.g. writing markup and coding. Web development can range from developing the simplest static single page of plain text to the most complex web-based internet applications, electronic businesses, or social network services.

    Feeds