I think one of the most important points of Reactive Programming Jafar brings up is that data can be pushed to a consumer and operated on when it is ready, instead of being stored and then fetched by a consumer later. This is important when you are trying to process real-time transactions and analytics; so you can keep data “moving” through its transformation process instead of “pooling” data in different stores (storage is a common point of back-pressure).
Also, as the producer now controls the workflow, the it can determine when to “dial-up/down” resources based on what its latency looks like; as well as better handle supervision of consumers -- if fault-tolerance is your thing ;)
Regarding the concept of Reactive Programming; it is not necessarily new, but more tooling is coming out that makes it easier to build in the general sense. Erlang with OTP has been commonly used in the past; Scala/Akka is becoming quite popular now along with GoLang paired with a queueing system such as 0MQ. In fact using Java with a JMS system such as HornetQ can be quite effective as well.
At the end of the day, think about having work being passed on to someone who can do it when it is ready, instead of placing work on someones desk and waiting for it to be done. With the former example, if no one were available to do the work when it is ready, being able to take an action right then and there (e.g. spin up a new node/actor/goroutine, etc.) when you know you need to can help reduce latency.
"Dont forget that SQL database still send raw text as request and get raw text in return!"
Depending on your database adapter, this is not the case. With Postgres, you have the Simple Query Protocol and the Extended Query Protocol (http://www.postgresql.org/docs/9.3/static/protocol-flow.html). A Simple Query involves text in and out. However with an Extended Query, properly parsed statements are always executed by the DB, and will always return properly typecasted data. You can also stream data to the client and use Cursors, if you have very large datasets (a life saver when reporting on large tables). Also, you don’t need to worry about SQL injection when using Extended Queries, as they are handled as prepared statements.
JDBC supports the Extended Query Protocol with Postgres, so if you are using Java, Scala, JRuby, or anything running on the JVM, you are good to go. But, I have not had to deal with raw text being returned from my Postgres queries in a long time ;)
I am an experienced software engineer that has a proven track record of successfully leading complex, highly scalable application build outs. Right now, I am growing a new consultancy, Reactive.IO http://www.reactive.io and am looking for clients who have difficult technical challenges and need to solve them right the first time.
I have an extensive background in using Ruby/JRuby on Rails, Java/Scala, Erlang, JavaScript/Node.js, PostgreSQL, and Amazon Web Services to build highly concurrent real-time API services and interactive single-page interfaces. I have routinely hired new software teams and worked with them to architect complex systems and create effective software development processes.
I also help companies build a technical strategy to ensure they start with, and transition to, technology that best fits their ever changing business needs. Furthermore, I have been a proponent of agile software development for over 10 years and excel at structuring product ideas into attainable sprints.
Between my engineering and management experience, my focus is to always reduce your company's technical risk. By having the right technology mix, partners, and people in play; you can then rely on your software to grow every aspect of your business.
To learn more about my background, please look at the following links and feel free to reach out to me at [email protected] anytime.
Location: New York City, New York; Postion: Ruby/JavaScript Engineers; Email: [email protected]
Ticket Evolution builds software and services that handles the real-time execution, clearing and settlement of event ticket trades. If you ever purchased a ticket to a sports game online or called a broker for seats to a concert, chances are our system was used somewhere in between.
We use Ruby on Rails, JavaScript with BackBone and Knockout, and PostgreSQL day-to-day; and are looking for engineers who are comfortable getting out of their comfort-zone.
If you are intersted in learning more, email me directly at [email protected]
For quite some time, I have been using Sequel (http://sequel.rubyforge.org) as an ORM with Postgres instead of ActiveRecord, and have never been happier. Overall, Rails has been a great web-framework, but ActiveRecord has been it's sore spot, at least for me.
Also, using the sequel_pg (https://github.com/jeremyevans/sequel_pg) on Postgres ensures that even raw SQL queries are type-casted properly, plus it supports streaming and cursors, while also being very very quick.
If you want to stick with Ruby/Rails and relational databases, but think ActiveRecord might not be your bag, give Sequel a shot. It also fits nicely into lighter frameworks such as Sinatra.
Location: Jersey City, New Jersey; Postion: Ruby/JavaScript/Erlang Engineers; Email: [email protected]
Ticket Evolution builds software and services that handles the real-time execution, clearing and settlement of event ticket trades. If you ever purchased a ticket to a sports game online or called a broker for seats to a concert, chances are our system was used somewhere in between. We recently closed a Series-A round and launched our newest partner cheaptickets.com.
We use Ruby on Rails, JavaScript with BackBone and Knockout, and PostgreSQL day-to-day. We are also starting to dive into Erlang and Riak and are looking for engineers who are comfortable getting out of their comfort-zone. Besides working on challenging problems, we also sport a 40-hour work week, have a laid-back office, and pay market salary along with equity and health insurance.
If you are intersted in learning more, email me directly at [email protected]
Location: Jersey City, New Jersey; Postion: Ruby/JavaScript/Erlang Engineers; Email: [email protected]
Ticket Evolution builds software and services that handles the real-time execution, clearing and settlement of event ticket trades. If you ever purchased a ticket to a sports game online or called a broker for seats to a concert, chances are our system was used somewhere in between. We recently closed a Series-A round and launched our newest partner cheaptickets.com.
We use Ruby on Rails, JavaScript with BackBone and Knockout, and PostgreSQL day-to-day. We are also starting to dive into Erlang and Riak and are looking for engineers who are comfortable getting out of their comfort-zone. Besides working on challenging problems, we also sport a 40-hour work week, have a laid-back office, and pay market salary along with equity and health insurance.
If you are intersted in learning more, email me directly at [email protected].
Ticket Evolution (ticketevolution.com) is the engineering backbone of the open ticket market. We build tools and an API that helps ticket brokers buy and sell event tickets from each other and to customers. Chances are if you bought a ticket online, it was from a website that uses our system.
Our systems use Ruby on Rails, Postgres and Redis (with Resque) for queueing, JavaScript and BackBone.js. We also have a lot of interesting challenges, such as scaling out an API that provides ticket inventory throughout the internet, guaranteeing orders are always processed correctly, and building responsive web-based applications.
If this sounds like fun, please send me an email at [email protected].
Also, as the producer now controls the workflow, the it can determine when to “dial-up/down” resources based on what its latency looks like; as well as better handle supervision of consumers -- if fault-tolerance is your thing ;)
Regarding the concept of Reactive Programming; it is not necessarily new, but more tooling is coming out that makes it easier to build in the general sense. Erlang with OTP has been commonly used in the past; Scala/Akka is becoming quite popular now along with GoLang paired with a queueing system such as 0MQ. In fact using Java with a JMS system such as HornetQ can be quite effective as well.
At the end of the day, think about having work being passed on to someone who can do it when it is ready, instead of placing work on someones desk and waiting for it to be done. With the former example, if no one were available to do the work when it is ready, being able to take an action right then and there (e.g. spin up a new node/actor/goroutine, etc.) when you know you need to can help reduce latency.
Hope that helps.