Bij onze software development trajecten werken wij met projectteams. Afhankelijk van het soort en de omvang van het project wordt een team samengesteld op basis van de specifieke technische kennis en kunde van de developers. Vaak bestaat een team volledig uit developers van Ibuildings, maar we werken ook in co-development teams waarbij naast developers van Ibuildings ook eigen developers van de klant aan het project werken.
Bij zo’n co-development traject is het noodzakelijk om extra aandacht te besteden aan een goede fundering voor het project. Naast een introductie in de tools die Ibuildings gebruikt bij software development projecten, moet er ook overeenstemming zijn over de werkwijze die aan het project ten grondslag ligt. Met andere woorden, ervoor zorgen dat we als team dezelfde taal spreken.
In the opening to this series, we discussed what ETags are and demonstrated their most common use case, caching. This time around, we’ll look at a lesser known but perhaps even better feature of ETags: keeping changes safe when writing to the server.
These last few years have seen the rise of some amazing frameworks oriented towards Single Page Application (SPA) like ExtJS, AngularJS, Backbone, Ember, etc. Following the trend where Front-end and Back-end separate. Client side technologies are now being managed by one team and Back-end services by another. This Separation of Concerns is wonderful for implementors as you only need a specification of the API and you can develop functionality concurrently. However all this client-side functionality often leaves the question: How are we going to secure the API if, at least in theory, it should be open for the browser of any device anywhere on earth? (no, we do not support the ISS).
Yet, ETags are one of the features that are the hardest to get right. Sometimes it’s not even clear how they work and while there’s a lot out there on the subject, it can also be difficult to put it all together. Developers frequently play either client and server roles in this exchange, which can make the responsibilities even more confusing.
In this series of blog posts, we’re going to look at ETags from both perspectives: First, a client trying to consume an ETag-enabled API. By focusing on the client side, we can focus on the features ETags offer and learn how these are supposed to look in a perfectly implemented world. In a later post, we’ll look at the gory details of how that API implements ETags and does the appropriate checks.
"If a tree falls in a forest and no one is around to hear it, does it make a sound?"
Likewise if a software project is delivered and no one has looked at security, can it be said to be secure?
If a tree falls... by Dunc(an) When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands (I need it to do X and also Y and Z... oh and can I get A?). And maybe some thoughts have been given to performance metrics, but security? Well... it "needs to be secure".
Episode: 2012 - 12 Ibon Tolosana
CocoonJS is a native wrapper for HTML5 canvas based applications/games.Without any code changes and thanks to its OpenGL canvas bindings CocoonJS is able to execute you applications with almost a 1000% performance boost.CocoonJS offers native iOS and Android deployment environment. It is highly focused on monetization since applications deployed in CocoonJS have out-of-the-box Ad networks and tracking systems integration. Other features like asynchronous websockets, localStorage, facebook integration, etc. are available too. All this magic is achieved directly, without cross-compilation processes or being limited to custom APIs.
The web has been a great place on desktops and laptops for quite some time, but with a booming growth of mobile devices like tablets and smartphones, the internet has become increasingly more interesting on these devices as well. Building mobile apps for the web has some advantages when compared to native development, before we start with Sencha Touch 2 we will take a look at these advantages.
Episode: 2012 – 09 Estelle Weyl
Mobile browser performance is challenged by bandwidth, battery, and memory constraints. Slow loading and reacting sites create bad user experiences. Sites that drain batteries or crash the browser are infuriating. Porting a web application designed and developed for desktop devices—devices with virtually unlimited memory, and literally unlimited power (they’re plugged in, not running on battery) in many cases just doesn’t work. By understanding mobile limitations and keeping mobile in mind throughout the development process you can create more responsive, faster downloading, less battery consuming applications.
Episode:2012 - 01 Pratik Patel
You've got a great idea for a mobile app. You have a team together. You're building the killer app. Do you know enough about the various app stores to know what to do next? How about pricing strategies for iOS and Android? Have you thought about the Nook Color and Amazon Fire? In this session, I'll bring my experience as CTO of TripLingo, an Atlanta company developing foreign language learning apps. TripLingo has been featured on the iOS store a dozen times, as well as the Android market and Nook store.
Episode: 2012 - 04 Ariya Hidayat
GPU acceleration on mobile browsers, if it is leveraged correctly, can lead to a smooth and fluid applications, thus improving the user experience. There has been a lot of mentions and best practices of hardware acceleration these days, although so far it has been pretty general and hasn’t provided much technical direction apart from simple magical advice such as “use translate3d”. This talk sheds some more light on browser interactions with the GPU and explain what happens behind the scenes, covering the topic of acceleration of primitive drawing, the use of tiled backing store, and composited layer. Knowing the actual machinery behind hardware acceleration, you will be in the position to plan your strategy to improve the performance of your web application.