- Whatever happened to programming? These days it is seems only glueing together a bunch of libraries... Where's the creativity? Well, I think you can now more and more focus on what your app can/should do, instead of re-inventing the wheel all the time. And if you have a real unique idea, you still will have to write those libs too :)
- Versioning REST services: "when developers need to create a new endpoint versus just adding data".
- A basic comparison between Kindle (JME) & Android Java development.
The best articles and links to interesting posts for technical team leaders building sophisticated websites, applications and mobile apps. Think about: software architecture, hardware architecture, design, programming, frameworks, scalability, performance, quality assurance, security, resolving issues, fixing bugs and Android.
Sunday, March 28, 2010
Best of this Week Summary 22 March - 28 March 2010
Sunday, March 21, 2010
Android SDKs, screensizes and resolutions: comparable hardware
The first table shows the different screensizes defined as per Supporting Multiple Screens | Android Developers, mapped on real existing devices.
Id | Screensize, resolution, physical | Comparable hardware |
---|---|---|
A |
|
|
B |
|
|
C |
|
|
D |
|
|
E |
|
|
F |
|
|
The table below shows which SDK supports the above screensizes.
SDK | Screensize Id |
---|---|
1.5 |
|
1.6 |
|
2.0 |
|
2.0.1 |
|
2.1 |
|
Remarks:
- The total nr of possible sdk+screensize combinations is 19!
- Android has organized the screensizes and resolutions into three generalized sizes and three generalized densities, see here.
- To support all these resolutions, you don't have to create icons/images for all possible combinations. By default Android tries to scale resources. Up to a certain limit it could be acceptable to let it do it for you, minimizing the number of images to create.
- An example setting is minSdkVersion = 3, targetSdkVersion = 4 (where 3 = 1.5, 4 = 1.6). Targeting 1.6 ensures that different screensizes can be supported if the device has 1.6 or higher.
- Cool skins you can find here. If you look at the configuration files, you can validate whether the screensize and resolutions are actually what you expect.
- Sources: Droid, Nexus One, Hero, Xperia X10.
Best of this Week Summary 15 March - 21 March 2010
- Twitter and Digg are moving from MySQL to Cassandra (a highly scalable second-generation distributed database, bringing together Dynamo's fully distributed design and Bigtable's ColumnFamily-based data model; a Facebook opensourced project). The reason for Digg for the move "is the increasing difficulty of building a high-performance, write-intensive application on a data set that is growing quickly, with no end in sight. This growth has forced them into horizontal and vertical partitioning strategies that have eliminated most of the value of a relational database, while still incurring all the overhead".
Twitter has about the same reason: "No single points of failure", "Highly scalable writes (we have highly variable write traffic)", and "A healthy and productive open source community".
Twitter tried HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra, and HyperTable amongst others before deciding to go with Cassandra. Interesting to read is how they slowly rollout Cassandra to limited sets of users.
An introduction to Cassandra to get it up and running can be found here. - A short post on how to implement Automatic testing Oracle Service Bus using Hudson, Maven and SoapUI.
- What to expect from HTML5 for webdevelopers.
Sunday, March 14, 2010
Best of this Week Summary 8 March - 14 March 2010
- How do the Spring 3.0 REST features compare to JAX-RS? Definitely also check the comments.
- Wicket IPageStore implementation using Hazelcast ("open source clustering and highly scalable data distribution platform").
Wicket now powers the mobile sites for Wallmart and Wellsfargo. Main reason for chosing Wicket: "... makes it easy to support multiple different types of devices. The walmart mobile application supports different HTML for three categories of devices (L1: iPhones & challengers, L2: BlackBerries, L3: Plain Old Devices). These three experiences are supported by the same Java code on the server side."
Great that the implementers have open sourced their components. Especially interesting is the 'wicket-stateless' component, since Wicket at its core is focused on managing stateful behaviour.
Also great to read is that in Wicket 1.5 support for variable/unknown URLs will be available. In that post you can also read how to do that in Wicket 1.4. - Great post on how MySpace tested their site live with 1 million concurrent virtual users (mixed with live users) using 800 EC2 instances. For example, the setup generated over 77,000 hits per second, not including live traffic. The article also includes 3 lessons learned.
- A short article on why eCommerce site Zappos (shoes and apparel) re-architected their site from Perl to a Java EE environment. Main reason for them was to better deal with scaling and demands on high performance. The website serves "millions of users/visitors daily and processes between 60-65.000 purchases every day". Includes some best practices, and a more-or-less infomercial on using Dynatrace as their application performance management solution.
Sunday, March 7, 2010
Best of this Week Summary 1 March - 7 March 2010
- Of course is the contract between webservices more important than their internals.
- How the static analysis tool Coverity was turned into a commercial product. Includes caveats, lessons learned etc.
Check also how you can measure code quality with Sonar. - The updated 2010 list of most dangerous programming errors.
- Four presentations from John Resig on jQuery, and especially Query 1.4.