Text

zeptojs swipe horitzontal - Part 1

Been researching on webkit touch controls recently and came across a feature that I wanted to replicate from Google+ iOS app (previous gen). I wanted a carded view but the user can swipe (flick) left to right to get a different card view. Quite similar to flickable.js. My only problem with flickable.js was that I wanted to scroll vertically on each card, and when the user swipes left or right, then the card would swipe.

Part 1 (still figuring out the rest) is to detect a left/right swipe. I’m using zepto.js just because of the small footprint. Code is adapted from zepto.js but slimmed down only for horizontal detection. Using the 80/20 rule, if the travelled distance on the x-axis is 80% more than the y-axis, this would be considered as a swipe on the x-axis.

Here’s the quick code:

$(document).ready(function(){
    var touch = {}
    $(document.body).bind('touchstart', function(e){
      touch.x1 = e.touches[0].pageX
      touch.y1 = e.touches[0].pageY
    }).bind('touchmove', function(e){
      touch.x2 = e.touches[0].pageX
      touch.y2 = e.touches[0].pageY
    }).bind('touchend', function(e){
      var xdist = Math.abs(touch.x1 - touch.x2)
      var ydist = Math.abs(touch.y1 - touch.y2)
      if ((xdist / ydist) >= 4) {
         if (touch.x1 < touch.x2) {
            alert("swipe right")
         } else {
            alert("swipe left")
         }
      }
      touch = {}
    }).bind('touchcancel', function(){
      touch = {}
    })
});

Next I’ll post up what I’ll do after the swipe event.

Text

Impressions of Play! Framework 1.2.4 vs 2.0

awfbeat:

Unless your a web application developer, what follows won’t be that interesting…

Early on in the development process of Awfbeat.com, we adopted the 1.2.x branch of the Play! Framework. For those who don’t know, Play! is a Java-based web application development framework that was finally able to provide for the Java community a comparable alternative to Ruby on Rails and Django. Its light-weight, simple, and designed for rapid application development from start-to-finish.

So far we couldn’t be happier with our choice, and have been excited to see support and adoption for Play! increase over the last year, with major hosting platforms like Heroku now supporting it natively in their stack (http://blog.heroku.com/archives/2011/8/29/play/) and players like LinkedIn taking a serious look at it (http://engineering.linkedin.com/34/play-framework-and-async-io).

With the recent introduction of Play 2.0 though, there seems to be a large amount of fear, uncertainty, and doubt (FUD) regarding whether new users should use the 1.2.x or the 2.0 branch of Play!. Having recently evaluated 2.0 ourselves, we thought we’d share our initial impressions of 2.0, and how it contrasts to our experience developing against the 1.2.x branch.

Play! 1.2.4 vs 2.0:

Currently, the two main reasons that justify adopting Play 2.0 over 1.2.4 are if:

  1. You want to do development in Scala instead of Java
  2. Your app needs to keep 10,000 or more concurrent connections open for 20 or more minutes, streaming data in real time… without consuming 10,000 threads in the JVM. (This use case is the entire reason for the development of Play 2.0)

Otherwise, Play 1.2.4 seems to be the way to go.

Play 2.0 should really have a new name like Play Scala or Play Safe, as it isn’t an incremental upgrade from the Play 1.x.x branch, but instead a completely new and different framework with its own set of tradeoffs.

As it stands today, Play 1.2.4 is the best light-weight Java Framework we’ve found, where simplicity and rapid application development are a priority, while still providing easy customization and impressive production-level scalability. Play 2.0 on the other hand really isn’t the best of anything today (maybe the best Scala framework), but it also isn’t intended to be. It’s intended to be the best framework around in 2 years… for the types of apps people will increasingly be building in 2 years time.

Read More

Photoset

quatermain:

AQGridView Lives!

For my iPad Dev Camp Hackathon project I’m releasing AQGridView, formerly known as KBGridView, written for the Kobo iPad application(iTunes link). It was designed to fill the role of NSCollectionView, with an API and internals based around UITableView. Full details are found on its GitHub project page.

It’s not necessarily 100% perfect yet (I’ve not written any test apps against the refactored/renamed code) but people here want to use it already, so up it goes.

Download it from GitHub.

Link

nosql:

If you’re a Java programmer you must have heard of the Spring sample app Pet Clinic. To showcase Cloudify, Gigaspaces guys migrated the Pet Clinic to Grails and used MongoDB to shard it:

Grails and MongoDB Pet Clinic

Original title and link: Spring Pet Clinic Goes Grails and Sharded on MongoDB With Cloudify (NoSQL database©myNoSQL)

Sweet!

Text

NoClassDefFoundError

Recently we encountered a really weird error while running Play! in IBM Websphere Application server. Our application being a simple Play! app was built and tested throughout all pre-production environments (development, test, etc) and they worked fine. One of our requirements was to build a deployable packaged .war file which worked in every environment (without repackaging it again) and the formula we used was as described here.

Low and behold, when the application was installed in production for the first time, all starts up fine, but upon hitting the first page, all we were getting was an 500 Internal Server error… Stack trace:

Internal Server Error (500)


Execution exception (In /app/controllers/MenuBuilder.java around line 18)
ExceptionInInitializerError occured : null

play.exceptions.JavaExecutionException
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:229)
at play.server.ServletWrapper$ServletInvocation.execute(ServletWrapper.java:540)

FOLLOWED BY:

   Caused by: java.lang.NoClassDefFoundError: utils.MenuConfigUtils (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:140)
at controllers.MenuBuilder.buildMenu(MenuBuilder.java:18)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:502)
at 

What we eventually found out was whilst initiating utils.MenuConfigUtils, a runtime exception was thrown causing it not to be loaded into Play!’s classloader. Thus the NoClassDefFoundError.

Thanks to this article, we managed to solve this issue and maybe to extend his conclusion when running Play! in a Java EE container, never throw a runtime exception. Thoughts?

Link

instagram-engineering:

One of the questions we always get asked at meet-ups and conversations with other engineers is, “what’s your stack?” We thought it would be fun to give a sense of all the systems that power Instagram, at a high-level; you can look forward to more in-depth descriptions of some of these systems in…

Excellent write up! Thanks again for sharing

Text

RIP Steve

Thanks Steve, for the IT world you’ve created…

Link

instagram-engineering:

With more than 25 photos & 90 likes every second, we store a lot of data here at Instagram. To make sure all of our important data fits into memory and is available quickly for our users, we’ve begun to shard our data—in other words, place the data in many smaller buckets, each holding a part of…

Link

folyo:

If there’s one thing nobody seems to want to talk about, it’s pricing. Most designers don’t publish their rates, and good luck getting a company to tell you how much they paid for their site.

The results of this situation is that it can be pretty hard to know how much to spent on design. Spend…

Text

“Power, so much power”

Looking back at my 10 years of java development in the enterprise environment, there are many words to describe the journey so far… enjoyable, satisfying, long hours, constant learning, frustrating…

I guess I’m still an engineer at heart, starting out my graduate degree as a mechanical engineer come java developer. Countless hours spent on learning Java, J2EE, and all the certifications under the SUN. It’s been fun. BUT so what? What have I been building? How fast have I been building MY enterprise applications? How many arguments have I gotten into regarding frameworks and best practices?

To be honest, I have walked the J2EE path with a blind sight, not wanting to admit that development is *slightly* slower than the other languages. Then came RoR. It looked nice, but I didn’t want to learn another language. I still believed that Java can do it just as good, and spend many years advocating Spring, Hibernate, Apache Wicket. Yet, I was only building about 1 to 2 applications a year. Not too big or small. Enterprise development is getting too heavy…

I don’t know how I missed Play! Framework when it was first released. TO me, it’s was a wonderful find. Since the discovery, we’ve started countless number of development projects. They may be throw away, but hey, at least it got started and we did something. Suddenly I feel as though all power has been restored back to Java in terms of Web Development.

My tangent to Play! for web development does not mean that I don’t like Java EE any more. But definitely will be my weapon of choice if the criteria fits. I’m no longer constraint to using a bazooka to kill an ant. A bazooka will definitely be handy when the time comes. But now I just got an ant to kill.

The point for this blog? (Since I don’t blog that much). I guess, I just wanted to say thanks to the founders and developers of Play! You guys ROCK! The move to incorporate Play Framework into Heroku has been even more amazing.

What’s next? Build more apps. Scala definitely when Play 2.0 comes out.