Socket applications

Editor's Notes

• #2: My name, where and how you can found me, joke in Italian.\n- I've been a developer for 6 years\n- Love open source development\n
• #3: My name, where and how you can found me, joke in Italian.\n- I've been a developer for 6 years\n- Love open source development\n
• #4: I’m from Brazil! A Great country, let they know a little bit about it.\n
• #5: This is São Paulo, where I live and work, a really big town, actually the sixth largest in the world\n
• #6: Actually I’m working on CodeMiner42 as Consultant and System Engineer developing Ruby applications, the propose is a true agile software development without bureaucracy and focused in Startups\n
• #7: Well now you already know who I’m, let’s gonna talk about what I came to speak to you guys, Socket Applications. In this talk I will answer three basic questions that we developers should ask ourself before start to use some technology, What, Why and How.\n
• #8: There is some web applications that the content traffic is constant. For example a chat, a livestream of feed or even public APIs.\nThe usual solution is use javascript to make Ajax requests in regular times to an server that will return the content that your application are looking for. This have a name, this is polling, and this is not the right way to do it.\n
• #9: There is some web applications that the content traffic is constant. For example a chat, a livestream of feed or even public APIs.\nThe usual solution is use javascript to make Ajax requests in regular times to an server that will return the content that your application are looking for. This have a name, this is polling, and this is not the right way to do it.\n
• #10: There is some web applications that the content traffic is constant. For example a chat, a livestream of feed or even public APIs.\nThe usual solution is use javascript to make Ajax requests in regular times to an server that will return the content that your application are looking for. This have a name, this is polling, and this is not the right way to do it.\n
• #11: There is some web applications that the content traffic is constant. For example a chat, a livestream of feed or even public APIs.\nThe usual solution is use javascript to make Ajax requests in regular times to an server that will return the content that your application are looking for. This have a name, this is polling, and this is not the right way to do it.\n
• #12: There is some web applications that the content traffic is constant. For example a chat, a livestream of feed or even public APIs.\nThe usual solution is use javascript to make Ajax requests in regular times to an server that will return the content that your application are looking for. This have a name, this is polling, and this is not the right way to do it.\n
• #13: \n
• #14: Basically we have two problems:\n\nRails and most of used languages to develop web applications don’t support multiples simultaneously connections.\nAn there is also the synchronous I/O, the real problem, if the server are saving an archive or doing a query in database this process have to wait before continue.\n
• #15: Basically we have two problems:\n\nRails and most of used languages to develop web applications don’t support multiples simultaneously connections.\nAn there is also the synchronous I/O, the real problem, if the server are saving an archive or doing a query in database this process have to wait before continue.\n
• #16: The solution is use a multi-thread model with an asynchronous I/O, change the procedural structure for another pattern, for a Reactor, an event handling pattern, as used by Event Machine. (Heroku, GitHub, 37signals, Engine Yard, PostRank). The idea behind Reactor pattern is instead of waiting on a response from network, use that time to process another request.\nIntelligently preload data.\n
• #17: The solution is use a multi-thread model with an asynchronous I/O, change the procedural structure for another pattern, for a Reactor, an event handling pattern, as used by Event Machine. (Heroku, GitHub, 37signals, Engine Yard, PostRank). The idea behind Reactor pattern is instead of waiting on a response from network, use that time to process another request.\nIntelligently preload data.\n
• #18: The solution is use a multi-thread model with an asynchronous I/O, change the procedural structure for another pattern, for a Reactor, an event handling pattern, as used by Event Machine. (Heroku, GitHub, 37signals, Engine Yard, PostRank). The idea behind Reactor pattern is instead of waiting on a response from network, use that time to process another request.\nIntelligently preload data.\n
• #19: An this is exactly what socket is about, the word "socket" as we know it, have some aspects there are related with the socket technology, basically a socket connection have the same concept of a socket when plugged, there's two fluxes , one that transmit the power to the machine and other that send back the power to the plug.\n
• #20: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #21: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #22: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #23: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #24: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #25: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #26: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #27: A normal application or web site, communicate with a server by patches, a user request a page or some information from your server, where your application are hosted, when this request get in the server, a connections is established, the server will do the pre-process necessary, and will serve the information the user are looking for, closing the connection.\n\nFor security reasons the connections is always requested or approved by the client, the server can’t figure out who is every client.\n
• #28: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #29: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #30: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #31: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #32: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #33: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #34: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #35: When we are talking about a connection with a socket server, everything start similar, but when the request made, get in the server and the connection is established ( the word used to describe a successfully connection is handshake ), it will never close the connections until you tell the system to do it or shutdown the server.\n\nUsually the sockets connections are grouped by channels, so you can have multiple channels and multiple clients connected in each one.\n\nIf you think just about a connection that never end, maybe you won't see all the benefits of this kind of application, when you have more then one client connected to this server you can start to think in the server like a bridge between all your clients, allowing they to interact each other, changing completely their experience in the application.\n\nIt actually gives you realtime connection between your servers and client browsers. You can literally push data to clients using your web application, you can push data from your server to your clients allowing interaction between users.\n
• #36: Why should I develop applications using socket technology? \n- The internet is not about being connected anymore, it’s about do it better, faster and simpler. \n- As faster as new technologies are coming the market are looking for innovation.\n- Users are looking everyday for applications that can offer a new way of getting and share information.\n- I'm not talking only about websites, games or any other specific kind of application, I'm talking about user experience\n- Sockets is one of the technologies that make possible a new range of applications, a network socket is an endpoint of an inter-process communication flow across a computer network.\n
• #37: Web developers are still stuck in the request/response mindset. every UI interaction results in a delay before another interaction can be performed. That's the process we've used our entire careers so it's no wonder most developers are blinkered to the alternatives.\n\nSpeed matters; a lot. Or to be precise, perceived speed matters a lot\n\ndevelopers still insist on using the request/response model. Even the introduction of Ajax hasn't improved the scene much, replacing blank loading states with spinners.\nUsers would just like to use your application without any interruptions.\n
• #38: Web developers are still stuck in the request/response mindset. every UI interaction results in a delay before another interaction can be performed. That's the process we've used our entire careers so it's no wonder most developers are blinkered to the alternatives.\n\nSpeed matters; a lot. Or to be precise, perceived speed matters a lot\n\ndevelopers still insist on using the request/response model. Even the introduction of Ajax hasn't improved the scene much, replacing blank loading states with spinners.\nUsers would just like to use your application without any interruptions.\n
• #39: Web developers are still stuck in the request/response mindset. every UI interaction results in a delay before another interaction can be performed. That's the process we've used our entire careers so it's no wonder most developers are blinkered to the alternatives.\n\nSpeed matters; a lot. Or to be precise, perceived speed matters a lot\n\ndevelopers still insist on using the request/response model. Even the introduction of Ajax hasn't improved the scene much, replacing blank loading states with spinners.\nUsers would just like to use your application without any interruptions.\n
• #40: Contribute for Single Page Applications concept.\nMore dynamic application with a better performance.\n
• #41: \n
• #42: There is a lot of ways to develop a socket application.\nBut you must start to think different, you must understand that isn’t all applications that can be converted to a client side app, you must start to think about architecture, about DCI (Data Context and Interaction) and patterns. The most useful pattern now a days are RestFull applications with an json interface\n
• #43: There is a lot of ways to develop a socket application.\nBut you must start to think different, you must understand that isn’t all applications that can be converted to a client side app, you must start to think about architecture, about DCI (Data Context and Interaction) and patterns. The most useful pattern now a days are RestFull applications with an json interface\n
• #44: There is a lot of tools that can provide you a simple or very complex environment to implement or even develop a whole application using frameworks focused in sockets applications.\n\nAn this are just some of the options, some of those are language independent, others use an external service as Pusher, there is the Juggernaut gem ( from Alex Maccaw ), and even a whole framework, the SocketStream a Node.js based solution, and another Cramp build on top of EventMachine for Ruby.\n\nThe most of those solutions have some relation with Redis.\n
• #45: There is a lot of tools that can provide you a simple or very complex environment to implement or even develop a whole application using frameworks focused in sockets applications.\n\nAn this are just some of the options, some of those are language independent, others use an external service as Pusher, there is the Juggernaut gem ( from Alex Maccaw ), and even a whole framework, the SocketStream a Node.js based solution, and another Cramp build on top of EventMachine for Ruby.\n\nThe most of those solutions have some relation with Redis.\n
• #46: You can run atomic operations on these types, like appending to a string; incrementing the value in a hash; pushing to a list; computing set intersection, union and difference; or getting the member with highest ranking in a sorted set.\n\nIn order to achieve its outstanding performance, Redis works with an in-memory dataset. \n\nDepending on your use case, you can persist it either by dumping the dataset to disk every once in a while, or by appending each command to a log.\n
• #47: You can run atomic operations on these types, like appending to a string; incrementing the value in a hash; pushing to a list; computing set intersection, union and difference; or getting the member with highest ranking in a sorted set.\n\nIn order to achieve its outstanding performance, Redis works with an in-memory dataset. \n\nDepending on your use case, you can persist it either by dumping the dataset to disk every once in a while, or by appending each command to a log.\n
• #48: You can run atomic operations on these types, like appending to a string; incrementing the value in a hash; pushing to a list; computing set intersection, union and difference; or getting the member with highest ranking in a sorted set.\n\nIn order to achieve its outstanding performance, Redis works with an in-memory dataset. \n\nDepending on your use case, you can persist it either by dumping the dataset to disk every once in a while, or by appending each command to a log.\n
• #49: Now let practice, I decide to introduce to you guys two solutions, one in Ruby, using Rails, and another one Node.js based.\nYou may asking yourself why those two.\nCause I love Ruby and Javascript, but also cause both has the best costs x benefits that I already used until now.\nI would give a try to Cramp too, and some more advanced tool as ØMQ but I don’t had the opportunity to get depth into those yet.\nBut why I love Ruby and Javascript? Cause both don’t make sense sometimes.\nI saw this talk on youtube from Gary Bernhardt and decide to bring this to you guys before we started with serious code.\n
• #50: Now let practice, I decide to introduce to you guys two solutions, one in Ruby, using Rails, and another one Node.js based.\nYou may asking yourself why those two.\nCause I love Ruby and Javascript, but also cause both has the best costs x benefits that I already used until now.\nI would give a try to Cramp too, and some more advanced tool as ØMQ but I don’t had the opportunity to get depth into those yet.\nBut why I love Ruby and Javascript? Cause both don’t make sense sometimes.\nI saw this talk on youtube from Gary Bernhardt and decide to bring this to you guys before we started with serious code.\n
• #51: Now let practice, I decide to introduce to you guys two solutions, one in Ruby, using Rails, and another one Node.js based.\nYou may asking yourself why those two.\nCause I love Ruby and Javascript, but also cause both has the best costs x benefits that I already used until now.\nI would give a try to Cramp too, and some more advanced tool as ØMQ but I don’t had the opportunity to get depth into those yet.\nBut why I love Ruby and Javascript? Cause both don’t make sense sometimes.\nI saw this talk on youtube from Gary Bernhardt and decide to bring this to you guys before we started with serious code.\n
• #52: Now let practice, I decide to introduce to you guys two solutions, one in Ruby, using Rails, and another one Node.js based.\nYou may asking yourself why those two.\nCause I love Ruby and Javascript, but also cause both has the best costs x benefits that I already used until now.\nI would give a try to Cramp too, and some more advanced tool as ØMQ but I don’t had the opportunity to get depth into those yet.\nBut why I love Ruby and Javascript? Cause both don’t make sense sometimes.\nI saw this talk on youtube from Gary Bernhardt and decide to bring this to you guys before we started with serious code.\n
• #53: Now let practice, I decide to introduce to you guys two solutions, one in Ruby, using Rails, and another one Node.js based.\nYou may asking yourself why those two.\nCause I love Ruby and Javascript, but also cause both has the best costs x benefits that I already used until now.\nI would give a try to Cramp too, and some more advanced tool as ØMQ but I don’t had the opportunity to get depth into those yet.\nBut why I love Ruby and Javascript? Cause both don’t make sense sometimes.\nI saw this talk on youtube from Gary Bernhardt and decide to bring this to you guys before we started with serious code.\n
• #54: You guys know what WAT means?\n
• #55: Lets talk about Ruby\n
• #56: Lets talk about Ruby\n
• #57: Lets talk about Ruby\n
• #58: Lets talk about Javascript\n
• #59: Lets talk about Javascript\n
• #60: \n
• #61: Lets stop talk about languages that sucks lets talk about javascript\n
• #62: Lets stop talk about languages that sucks lets talk about javascript\n
• #63: Lets stop talk about languages that sucks lets talk about javascript\n
• #64: Lets stop talk about languages that sucks lets talk about javascript\n
• #65: Lets stop talk about languages that sucks lets talk about javascript\n
• #66: Lets stop talk about languages that sucks lets talk about javascript\n
• #67: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #68: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #69: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #70: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #71: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #72: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #73: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #74: \n
• #75: \n
• #76: \n
• #77: \n
• #78: \n
• #79: SocketStream is an open source Node.js web framework dedicated to building single-page realtime apps.Whether you're building a group chat app, multiplayer game, trading platform, sales dashboard, or any other realtime web app, SocketStream gets you up and running quickly by providing essential functionality and a rapid development environment.\nOn the client-side, you're free to use all the technologies you already know and love - such as jQuery, Mustache, Backbone.js, Ember.js, Angular.js\nSocketStream apps can easily be deployed to Nodejitsu, EC2 servers or any other hosting platform supporting websockets (sadly that excludes Heroku for the moment).\nWorks great with Chrome, Safari, Firefox 6 (and above) using native websockets\n\nWhen you run in production mode these files are automatically packed and minified into one CSS, JS and HTML file per-client.\n\nOptionally use Redis for fast session retrieval, pub/sub, list of users online, and any other data your app needs instantly\n
• #80: SocketStream is an open source Node.js web framework dedicated to building single-page realtime apps.Whether you're building a group chat app, multiplayer game, trading platform, sales dashboard, or any other realtime web app, SocketStream gets you up and running quickly by providing essential functionality and a rapid development environment.\nOn the client-side, you're free to use all the technologies you already know and love - such as jQuery, Mustache, Backbone.js, Ember.js, Angular.js\nSocketStream apps can easily be deployed to Nodejitsu, EC2 servers or any other hosting platform supporting websockets (sadly that excludes Heroku for the moment).\nWorks great with Chrome, Safari, Firefox 6 (and above) using native websockets\n\nWhen you run in production mode these files are automatically packed and minified into one CSS, JS and HTML file per-client.\n\nOptionally use Redis for fast session retrieval, pub/sub, list of users online, and any other data your app needs instantly\n
• #81: \n
• #82: \n
• #83: \n
• #84: \n
• #85: \n
• #86: \n
• #87: \n
• #88: \n
• #89: Is super simple and easy to get going. As I said the juggernaut also use Node.js server.\nIt is supported by the most commons browsers in desktop and mobile.\n
• #90: \n
• #91: \n
• #92: \n
• #93: My name, where and how you can found me, joke in Italian.\n- I've been a developer for 6 years\n- Love open source development\n
• #94: My name, where and how you can found me, joke in Italian.\n- I've been a developer for 6 years\n- Love open source development\n
• #95: My name, where and how you can found me, joke in Italian.\n- I've been a developer for 6 years\n- Love open source development\n