There are several ways to cross compile Go programs, but the way we’re going to show you is awesome because you don’t have to install any libs or anything. That said, you do need Docker installed, but you already have that anyways, right?
Our friends at Treasure Data wrote a blog post about data collection in Ruby and how to run multiple data collection tasks in parallel (or scheduled) using IronWorker. The example from Treasure Data demonstrates what it takes to build a simple logging application in Ruby with IronWorker to manage and log the output to Treasure Data, which can then perform queries.
As noted in the blog, this example is not a complete solution but an illustration to show users what’s possible when combining Iron.io and Treasure Data. Big thanks to John Hammink and the Treasure Data team for their work to educate the community.
Here’s an excerpt from the original post:
Today, the world revolves around developers. Digital businesses are becoming a significant part of the landscape. Traditional business thrives on its responsiveness to customers and how it handles business data. People used to talk about the Era of Information Technology, however now we’re in the Era of the Developer.
Fast-moving businesses recognize the need to give developers the tools, platforms, and application services developers require to get things done. Equally important is getting obstructions out of the way of developers and allowing them to move fast. What do developers need to be successful in this modern world? They need self-service, on-demand capabilities, immediate scale, and little to no operations. Simply put, developers want to write code – and do so in a manner that lets them focus on writing code without having to manage tools and infrastructure. The overhead of managing infrastructure or dealing with a mismatch between development and production systems, steals precious cycles from a developer’s main driver – writing code.
Slack has a great API for building integrations and one of those types of integrations is called a “bot”. Bots are useful tools that can respond to messages the chat users type into a chatroom. For instance you could type in “what is the weather” and the bot would respond with today’s weather.
Bots are simply software programs that run on a server somewhere and when someone types in a special sequence of characters, in Slack, these usually start with a ‘/’, the message is sent to the bot. The bot then responds with whatever answer it wants to give and that answer is posted back to the chatroom.
Way cool. Buuuut… you have to run the bots on a server somewhere that Slack can communicate with and it always has to be running whether it’s being used or not. True PITA.
Iron.io is a proud sponsor of the AirPair $100K developer writing competition. As part of our community engagement, we invite you to submit a post for a chance to win a $500 prize for best Iron.io article. Posts can take the form of your narrated experience using Iron.io in production – including problems solved, lessons learned and wisdom gained.
To kickstart ideas on topics we’d love to read about, here are key areas of interest:
- Tell us about your experiences applying event-driven asynchronous processing or moving from a monolithic app environment to a microservices architecture.
- What are the “Top 5” reasons you choose IronMQ/IronWorker to accelerate your distributed computing deployment.
To enter a post or for more details about the competition, go to: https://www.airpair.com/100k-writing-competition
Good luck. We look forward to reading your submission.
When using the word ‘ephemeral’, it’s hard not to think of Snapchat these days, however the concept applies to the on demand computing pattern we promote here at Iron.io with our task processing service IronWorker. At a glance, each Docker container in which a task runs is only alive for the duration of the process itself, providing a highly effective environment for powering applications that follow the microservices architectural style.
Continue reading “The Ephemeral Life of Dockerized Microservices”
If imitation is the sincerest form of flattery, then consider us flattered by Amazon. The new AWS Lambda service is nearly the same thing as Iron.io’s IronWorker service, solving the same problem with a slightly different API.
I took it on as a project recently to compare and contrast how each service works, how they are similar, and how they differ.
This post is the results of that comparison.
Continue reading “AWS Lambda vs IronWorker”
FFmpeg is the leading cross-platform solution to record, convert and stream audio and video. Dealing with audio and video can eat up resources, making the activity a great fit for IronWorker by moving the heavy lifting to the background.
In the past, usage of FFmpeg with IronWorker would require that our users include and install the dependency within each worker environment. In order to streamline that process for developers, we’ve included FFmpeg in an IronWorker stack as a custom runtime environment specifically meant for video processing. Continue reading “New FFmpeg IronWorker Stack For Easy Video Processing”
|Package your dependencies on IronWorker using composer|
This is a tutorial describing how to include and use the PHP package management tool Composer with IronWorker.
Composer is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs, and it will install them in your project for you. Packagist is the main Composer repository. It aggregates all sorts of PHP packages that are installable with Composer.
|Using IronMQ and Python to as a Buffer between Systems|
Connecting systems and moderating data flows between them is not an easy task. Message queues are designed for just this purpose – buffering data between systems so that each can operate independently and asynchronously.
Here’s a short article on using IronMQ to buffer a CMS system from real estate data from a listing service. The app developer uses Python for the bridge code between the service and the CMS system. Continue reading “Message Queues for Buffering: An IronMQ and Python Case Study”