Client-side JavaScript running on Server? Yes makes sense!
When I first time red about server-side JavaScript with node.js one of (many) arguments from proponents were a possibility of code re-use from browser on server. As a showcase for that feature many people were pointing to Yahoo sample where YUI elements were rendered on a server in case browser does not support JavaScript (link).
To be honest for me at that time it was the smallest possible advantage of server-side JavaScript. I was much more interested in non-blocking structure and single-threaded/lock-free execution. But now I can confirm, using the same language on the server side and client-side gives a significant advantages. Not only in terms of re-using concepts and techniques but a practical code re-use.
Marketing Automation with Twitter and Klout
Twitter is doubtless an excellent marketing medium for any kind of company. Unfortunately too many companies are not exploiting Twitter’s marketing potential. They are just concentrating on publishing some content that is consumed by the followers. What if your company or product is mentioned on Twitter by somebody? Do you react on that in any way?
We at elastic.IO believe that you must not ignore any of the mentions. Why? Just imagine that some very respected person X stumbles upon your product, fells in love with it immediately and mentions you on twitter. In such a case you should retweet the mention in order to tell your followers that person X likes your product. If you miss such an excellent marketing opportunity, well, it’s all your own fault.
How we use Amazon CloudFront for dynamically generated content
As you might know from the previous blog entry we store integration flows created by our users in Github Gists created on user’s behalf. This gives our users a full ownership of their data and gives us a great storage, collaboration and versioning concept from Github.
Displaying your customers on Google Maps
Since a couple of weeks we at elastic.io are inviting people to sign up for a private beta account. When signing up, our potential customers may allow us to contact them for feedback. Some of the beta subscribers are very interested in a possibility to display their customers on a map. We found this use case very interesting and implemented it. This is how a flow might look like.
Links in your tweets, who click on them and how often?
We were thinking about a simple question lately: How many clicks were made on links in our tweets, or links in other people tweets that were twitting about our website?
This is an essential information that will not only allow us to estimate how much each tweet ‘worth’, but also see how we can engage with our twitter followers better. We did a short research on that topic and that’s how it looks today (6 May 2012).
Featured on HackerNews and BetaList. Comparison and statistics.
About three weeks ago we opened a private beta registration at elastic.io. And by that date we started to think about how to attract visitors to our website. There were many ideas and actions related to them, however here I would like to talk about two major events in our user acquisition activities:
Protecting you from billing surprises
One of the key features of elastic.io is the control of costs produced by consuming APIs. For example, last week we submitted a link to our blog post at Hacker News. The topic described in the post attracted attention of many hackers who went to our website and our blog. The page visits increased to 5000/day. We have got more than 200 beta subscribers within few hours.
Our beta subscription form is built with Wufoo. So far, we have been using a free account which is limited to 100 entries/month. It was sufficient until we posted a link at Hacker News. Fortunately, Wufoo guys informed us that we are about to reach the free limit. Once the limit is reached, Wufoo would not accept any new entries and we would lose potential beta users. Thanks to Wufoo’s notification, we increased our limit early enough by upgrading to a paid account.
On paid accounts, if we exceed the number of entries allowed for the month, Wufoo would charge a fee of $0.05 USD per entry over the limit at the end of the billing period. While $0.05 USD per entry seems to be an acceptable fee, there is potentially a danger of a billing surprise at the end of the month.
If you are using services like AWS or Twillio, the billing surprise might be even more scary. Just imagine you are hosting your website at Amazon. The average visitor count is 1000/day. Now if you write an interesting blog post that will attract attention of many readers, as our post did, your costs might explode because thousands of users visited your blog or website. Check out the Amazon EC2 prices to get an impression why cost control is important.
Another example is Twillio. For every incoming or outcoming text message Twillio is charging $0.01 USD. There are no pre-paid limits, you just pay for every single message. Can you foresee how many text messages you will get or send in the next month? Again, cost control is very important here.
This is where elastic.io can help you. If you are consuming the Web APIs using elastic.io, you will have the costs control in your hands. We are working on a solution that will inform you about unexpected API usage, even if the particular API doesn’t support that. With elastic.io, you will be able to define your own cost limits. If required, we can recharge your account on demand.
For example, in case of Twillio you will be able to define a cost limit for a day, week or a month. Let’s say your limit is 1000 messages/day. Now if, for whatever reason, your application needs to send 10000 messages on a single day, we might send the first 1000 messages directly and store the remaining 9000 messages in our system and inform you about that. It’s up to you to decide what to do with these messages. You can accept the costs and send them directly or you can tell us to send the messages in the next days if there is remaining free quota.
Got curious? Subscribe for free beta account here.
Your data is owned by you!
We did a major change recently. You may notice on our login screen that you are no longer require a Twitter account to sign-up. Now you need a Github account. There are two reasons behind this change:
- If you have a github account, then you are most probably a developer, more over you are a good developer with an understanding for open source and open collaboration. So, we want you to try elastic.io.
- We don’t want to lock your data in our databases.
Last point is very important for us. We believe in data portability. In the world of SaaS and online platforms like Google, Facebook, etc. (private) data is very important. So we don’t want to lock your (flows) data in our systems, therefore now we store them as Github Gists!
That’s how Github describes gists:
Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository.
You can create, edit, delete your gists. Gists could be public or private. And the most interesting of all you can fork other people’s (public) gists!
For example check this out:
https://gist.github.com/2161825
This integration flow loaded in the Designer will looks like this:
With this new storage you own your flows. The flow data is stored and available under your Github account. You can also see full history information and forks other people did on your gists!
It’s also important to note that now (just as before) your integration flows contain no private information like usernames, password, OAuth keys, etc. So you can easily share them with other people (as long as Gist that you create are public).
So if you want to try it out, register for our private beta on: http://elastic.io
Betapitch was allot of fun
On Mach 10th team of Elastic.IO pitched our product on Betapitch Köln. We didn’t won the prize, however we had allot of fun and have got a great feedback! Here you can read a blog post about this event.
