Last weekend was marked by the 5th edition of the PHPBenelux conference. Being psyched already about the previous editions of the conference, we were keen to see what they had in store for us at their first lustrum...
What started as a dream for a worldwide library of sorts, has transformed into not only a global repository of knowledge but also the most popular and widely deployed Application Platform: the World Wide Web.
The poster child for Agile, it was not developed as a whole by a single entity, but rather grew as servers and clients expanded it's capabilities. Standards grew along with them.
While growing a solution works very well for discovering what works and what doesn't, it hardly leads to a consistent and easy to apply programming model. This is especially true for security: where ideally the simplest thing that works is also the most secure, it is far too easy to introduce vulnerabilities like XSS, CSRF or Clickjacking.
Because HTTP is an extensible protocol browsers have pioneered some useful headers to prevent or increase the difficulty of exploiting these vulnerabilities. Knowing what they are and when to apply them can help you increase the security of your system.
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.
Afgelopen woensdag hadden we de laatste interne workshop van het jaar en deze ging over de best practices met Vagrant en Chef.
Ibuildings organiseert regelmatig een interne workshop. Hierbij worden (veelal) technische onderwerpen behandeld en aan de hand van een opdracht verder uitgewerkt.
Maar hoe maak je een workshop over Symfony 2 en Domain Driven Design (DDD) interessant voor iedereen?
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.
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 - 15
In this session, Tommy Maintz will guide you through building an HTML5 mobile web application using the latest release of Sencha Touch 2.
Episode: 2012 - 26
The "it works on my machine" mentality has resulted in numerous face palm moments. This is even more painful when a your app is under heavy load due to a marketing campaign. With some minimal code changes and some smart utilities, you can maximize your scalability and performance. Keywords: Varnish, PHP-FPM, Nginx, APC, CDN, Gearman, Memcached and a proper server setup. I'll show you how you can make a slow app with a crappy code base go mighty fast on one and even multiple servers. The focus of this talk is to cure first and eventually learn and prevent.
Episode: 2012 - 10
Sam de Freyssinet
Business owners have woken up to the reality that the web is increasingly consumed on the move. Product owners are demanding new mobile sites that must be released yesterday! You manage an established online business, now you need to move into the mobile market. How do you take your existing business into a mobile domain? Does the entirety of your current business model need to exist in the mobile environment? Or is there a killer mobile app hidden within your existing product? This talk will walk through ten considerations that you must make when moving your online business to a mobile audience.
Episode: 2012 - 30
Creating a good, useful and functional API for your application can be one of the most difficult parts of a project. With more and more things becoming API-powered, it's important to plan well and provide what the user expects. I'll look at some principles you can follow to make sure the API you write is the right one, both from the developer perspective and what you, as a user, should expect of a quality web service API.
Episode: 2012 - 12
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.
Episode: 2012 - 16
Continuous Integration has typically been a practice only performed by companies who want that piece of mind for their client software, but does it need to be like this? Travis CI is a continuous integration service for the open source community. We make testing OS projects dead simple and fun. But most importantly, we help improve code quality for large projects like Doctrine2 and symfony, to smaller libraries like FOSRest. The vision behind Travis CI is to become for builds what PEAR is for distributing libraries. In this talk Josh, one of the core members of the Travis CI team, will introduce you to the vision behind Travis, the how it is implemented, and why it matters to everyone in the OS community.
The web as a mobile platform
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
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 - 27
Elizabeth M Smith
The standard PHP library (SPL) is growing in both maturity and use. But a lot of developers still aren't aware of the tools in SPL or simply haven't seen good examples of how to use the code. From interfaces to an autoload stack to classes that make objects act like arrays, there are tools to make every application leaner and faster, or simply more clever. Using live projects from github, take a look at the good, bad, and the ugly of SPL usage in PHP development.