Ori Pekelman
CTO of af83
af83
Currently CTO of AF83 a young and vibrant company based in Paris with offices in San-Francisco specialized in collaborative real-time web and mobile applications.
In France, one of the promoters and organizers of Barcamps and other community activites, including the French DrupalCamps, RailsCamps and the very successful 2009 DrupalCon Paris. AF83 is a multi-tech shop with developments in Ruby on Rails, Erlang and Server Side Javascript and even some cool PHP stuff. The company specializes in the rapid development of scalable architectures leveraging the latest technologies in NoSQL, automatic deployment and light-weight RESTful SOAs.
Though young, AF83 has been called upon by major industry leaders in France (and now some overseas) to realize some very cool sites. Among them different social portals for SFR (the French Vodafone subsidiary), a dematerialization project for La Poste (the French Postal services), a Web Services architecture for the Laser group, an internal innovation management system for CapGemini, a fashion designers C2C market place for les 3 Suisses, widgets for Google, platforms for the 2007 French presidential campaign, just to name a few; On the other hand, AF83 realizes the initial developments for early stage funded start-ups launched by industry veterans.
Formerly IT strategist for aSmallWorld.net, an exclusive social networking site, Chief of R&D at Internet Patrol specialized in strategic information retrieval on the Internet for the luxury industry and CTO of Omikron Delta LTD specialized in Technical computing software.
In France, one of the promoters and organizers of Barcamps and other community activites, including the French DrupalCamps, RailsCamps and the very successful 2009 DrupalCon Paris. AF83 is a multi-tech shop with developments in Ruby on Rails, Erlang and Server Side Javascript and even some cool PHP stuff. The company specializes in the rapid development of scalable architectures leveraging the latest technologies in NoSQL, automatic deployment and light-weight RESTful SOAs.
Though young, AF83 has been called upon by major industry leaders in France (and now some overseas) to realize some very cool sites. Among them different social portals for SFR (the French Vodafone subsidiary), a dematerialization project for La Poste (the French Postal services), a Web Services architecture for the Laser group, an internal innovation management system for CapGemini, a fashion designers C2C market place for les 3 Suisses, widgets for Google, platforms for the 2007 French presidential campaign, just to name a few; On the other hand, AF83 realizes the initial developments for early stage funded start-ups launched by industry veterans.
Formerly IT strategist for aSmallWorld.net, an exclusive social networking site, Chief of R&D at Internet Patrol specialized in strategic information retrieval on the Internet for the luxury industry and CTO of Omikron Delta LTD specialized in Technical computing software.
Ori Pekelman is Giving the Following Talks
A match made in Scalability Heaven. Mongo with Erlang.
Let's take the following for-granted: Doing security, Privacy and Scalability last is a bad idea.
But you do not engineer a system that is supposed to have at the most a thousand users the same way you engineer a system that might have millions of them. That said, when you are constructing a Framework the assumptions you make on the use cases and number of users are at best a wild guess. Developers are like that, crazy. Even if you get a lot of really smart people in a room there is a very good chance you'll get it wrong. Enough to look at the IPV4 address space... but if IPV6 addresses were implemented at the beginning of the Internet the network overhead might have been unacceptable. Maybe the whole thing would not have worked. So one of the major issues when designing a new system that does not have a very strict, limited and stable use case, is writing only the code of the scalability you need while deferring that of future needs while having a very strong notion of why there are no strict impediments for it to scale later.
We will look at some of the design decisions at the heart of U.C. Engine our Realtime Collaboration Framework, and see why choosing a documented oriented store as a persistence layer is a good idea when there are some assumptions that are too early to be made. Why and how it allows us to defer some of the scalability issues. We'll look specifically at MongoDB that we chose it side by side with Mnesia. We shall examine the issue of impedance mismatch between records and documents. And to get really down to the nitty gritty stuff we will also take a hard look at the current state of MongoDB libraries in Erlang. Why we chose emongo, what we learnt from this about the state of libraries in Erlang and how this effects doing a larger web oriented open source project.
But you do not engineer a system that is supposed to have at the most a thousand users the same way you engineer a system that might have millions of them. That said, when you are constructing a Framework the assumptions you make on the use cases and number of users are at best a wild guess. Developers are like that, crazy. Even if you get a lot of really smart people in a room there is a very good chance you'll get it wrong. Enough to look at the IPV4 address space... but if IPV6 addresses were implemented at the beginning of the Internet the network overhead might have been unacceptable. Maybe the whole thing would not have worked. So one of the major issues when designing a new system that does not have a very strict, limited and stable use case, is writing only the code of the scalability you need while deferring that of future needs while having a very strong notion of why there are no strict impediments for it to scale later.
We will look at some of the design decisions at the heart of U.C. Engine our Realtime Collaboration Framework, and see why choosing a documented oriented store as a persistence layer is a good idea when there are some assumptions that are too early to be made. Why and how it allows us to defer some of the scalability issues. We'll look specifically at MongoDB that we chose it side by side with Mnesia. We shall examine the issue of impedance mismatch between records and documents. And to get really down to the nitty gritty stuff we will also take a hard look at the current state of MongoDB libraries in Erlang. Why we chose emongo, what we learnt from this about the state of libraries in Erlang and how this effects doing a larger web oriented open source project.
