A while ago I wrote a blog post comparing two approaches to the all new and shiny Flux architecture The comparison included reference implementation as described by its authors at Facebook and one of the many alternatives - the Reflux, created by Mikael Brassman. At the time, new implementations of the Flux pattern were springing up at an astonishing pace: Flummox, alt, Fluxxor, to name just a few of countless examples. At some point, one of the libraries started getting a lot of traction in the community and gained the status of a de facto standard. The library I have in mind is of course Redux, created by Dan Abramov. While many of the alternative libraries are still developed and can be a a great option to use in your application, there’s no doubt that Redux has become a weapon of choice for most of the React developers in need of a state management solution. In this post we’ll take a look at features that made Redux stand out from the crowd. We’ll also build a simple app to demonstrate how it differs from the alternatives. We’ll also learn about some good patterns that are not mandatory but can be very helpful for writing maintainable code.
Elixir and Ruby look alike. This is very much understandable, since José Valim was involved in Ruby ecosystem before he switched to become a language designer and maintainer. Both languages are strongly and dynamically typed, share similar method/function/module definition syntax, and overall layout of source files is similar.
In May, we had a pleasure to organize already 2nd edition of Rails Girls programming workshop in Bialystok. This year we decided to double the number of participants. We invited 44 women and 1 man who together with 15 mentors formed 15 groups (3 mentees and 1 mentor in each team).
In Erlang and Elixir, process is something entirely different than operating system process. In simplest words: it is a hybrid between thread and and object. Ok, maybe that’s not that simple, let’s have a look at example of simple process:
There have been good posts written about creating Elixir libraries already. One awesome recent post can be found here. It will walk you throught the process of writing, documenting and publishing your first Elixir library really well.
At AmberBit we still mostly develop Ruby on Rails applications for our clients. For about a year now, however, we have been looking at Elixir programming language and it’s ecosystem, to help us solve problems that Ruby (and Rails) fail to address. We used Elixir with client’s projects already, and the experience was generally positive.
In the lifetime of most successfull Rails applications, comes a moment, when it will have to speak many languages. If a developer did not thought of such possibility at the very beginning of the project, that will cause some trouble and manual work. There are so many places where it was just easy and convenient to use static texts (most likely in English), that at this point this will imply digging through the source code and manually searching for strings. The most tedious part of whole translation process is ealing with dozens of views, controllers and mailers. That’s where most of the strings presented to the user live.
You are planning to build something in 2016, aren’t you? Some decisions have to be made, team to be hired. For a few years now you have been relying on Ruby (and Rails) for all your work and you have been reasonably happy. You have been hearing a lot about this new Elixir thing and considering giving it a shot? Let me tell you a bit more about it and help you make a good decision.
At Amberbit, we have a legacy project which uses MongoDB. We’ve been working on it for few years now. Through this time it obviously grow and changed a lot and at some point we started focusing more on it’s performance. The biggest issue we had was that we were using mongoid and mongoid/moped, which not only caused memory leaks (rack mini profiler) but also had an impact on performance as we needed to run really complicated queries that non-relational database couldn’t handle well. That’s why we agreed on switching to PostgreSQL.
As Ruby on Rails developers we get used to hosting our apps on platforms such as Heroku, which make configuration and deployment fairly easy. Sometimes, however, we want to have more control over server configuration and all of the steps of deployment, backup or monitoring. VPS providers like AWS EC2 or DigitalOcean droplets come in handy in such cases. Maintaining those may be not as simple as in case of Heroku, but there are few automation tools written in ruby (e.g. Capistrano, Chef) that make this task easier.
Few months ago I had the opportunity to be a part of the team that organized the very first Rails Girls Bialystok. The idea was to encourage women to become part of the IT community by organizing one of worldwide Rails Girls events.
What is an engine? And a mountable one? In Rails world it’s just a piece of code, which plugged to existing application, extends its basic functionality. Good examples would be: ActiveAdmin, AmberBit’s Translator or Devise. Also Rails application is example of an engine.
Recently I’ve been working on a Ruby on Rails project, which requires access to Google Calendars of multiple users. I decided to use Sorcery for registering users via Google and receiving access to their calendars. Unfortunately, it turned out that synchronizing calendars’ data was slightly more complicated than I initially anticipated. Here’s how I did it.
Search engine optimization (SEO) is the process of optimization of a website, which main purpose is to make it more visible among results from search engines (such as Google). There are tons of practices, tricks and tips that can be applied to improve a website in terms of SEO. Lets start with some basics.
At AmberBit we use AngularJS, and it is slowly becoming our second framework of choice after Rails. We won’t run away from Ember either, but Angular is significantly easier to pick up, and to introduce incrementally in existing projects. Oh, and there are some awesome libraries out there that make it even more productive.
At AmberBit we not only work on small MVPs or prototypes for emerging start ups. We have a solid base of long-term customers, and we have to support their application not for months, but for years. All applications tend to grow in time, and issues such as technical debt and bad architectural decisions can arise, and bide you after many months the mistake was made. There has been a lot of talk recently about making the applications more modular, to tackle this as well as other problems, such as performance. But how would one do that? I’ll explain you my approach.
Some time ago I wrote a post highlighting some the Ruby features that I find to be its strong points. The list was by no means exhaustive. Such list would be really long, as I believe there are many things that Ruby got right.
We often come to the point, when we have to write enormously huge module in Ruby. But we simply don’t want to. Maybe because we’re too lazy/smart, or we do know that such library already exists written in C/C++. Implementing pthread or crypt library in pure Ruby sounds like reinventing the wheel. The other thing is well-written C code most likely will perform much better than any higher-level implementation. It takes advantage of pre compilation, better garbage collection or static typing.
Ruby is a programming language designed by Yukihiro “Matz” Matsumoto, with a focus on programmers productivity and fun. The author stated it himself many times in interviews and talks, such as Google Tech Talk in 2008: “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.”
Ruby on Rails is our usual framework of choice to build web applications at AmberBit. It is good and easy to use, but let’s face it: it’s massive compared to more lightweight frameworks, such as Sinatra. Why is it bad? There are a few reasons and slow start-up time and high resources usage are just two most common concerns. Slimming down Ruby on Rails applications can allow you to use different components (say Sequel instead of ActiveRecord) and improve system security. Remember the last year’s security dramas related to JSON parameters parsing? It would be largely irrelevant for most applications if everyone who does not use it, disabled it.
Capybara is a tool that Ruby on Rails developers mostly use for testing their web applications. This tool, however, can be also used to automate boring/repeating/long running tasks on the web or scraping information from web sites that were not kind enough to provide API.
PostgreSQL is the true awesome SQL database, that you should probably be using for your relational data in your Ruby on Rails applications. In fact, if you are using Heroku, you are quite likely using PostgreSQL already. If you are not using PostgreSQL, or just starting, you have no idea how awesome it is. In this post, I will walk you through some basics that all Ruby on Rails developers who use PostgeSQL should know about.
Developing AngularJS and Rails applications is our favorite way to build web applications at AmberBit. Why Angular? Because it allows us to finally separate user interface from Rails back-end. The promise of building an API along with your application is also much easier to meet when combining both frameworks. Learn how to integrate views in those two.
Torquebox is JRuby application server based on JBoss. What’s an application server? It’s a bundle of web server, messaging queue, JRuby runtime and websocket infrastructure. It is pretty cool and we use it in AmberBit to deploy a few hight-traffic web applications we developed for our clients.
At AmberBit we develop Ruby on Rails web applications for clients that are start-ups in different areas. One of the clients required detection of near-duplicate images, which allowed us to explore the area of content-based image retrieval systems, existing commercial solutions, advanced algorithms such as SURF and computer vision libraries. We’re more than happy to share the knowledge in this multi-part blog posts series, but we’ll start small with simple solutions that might be just fine for you and Ruby on Rails application that you develop.
You probably heard that rendering views outside controllers is pure evil. That’s true, but there are cases where it is very handy to render partials or views defined in your Rails application in different places. Think about generating newsletter templates and saving them to database, or generating bits of static HTML that need to be saved to filesystem. You will learn how to do it from this article.
There are many ways you could implement FLV video streaming. The most “proper” way to do it is to use RTMP (Flash Media) Server, which you can purchase directly from Adobe. A few cheaper/free/open source alternatives exist. For me, most promissing one is Mammoth, but it’s still in early stage of development. However, most popular alternative is Red5, however I didn’t find it either easy to configure or being reliable at serving files. Some big guys are using it, but it takes time and experience to set it up and maintain properly.
Open Social is a standard for developing applications for social network sites that was introduced by Google. The standard was not welcomed with ecstatic applause, however more and more social networks started to embrace it. It evolved over time and today, Open Social is supported by such big players as MySpace, Orkut or VZ network. It’s basic competitor is framework used on Facebook, currently the biggest player on the market, and they share the same basic concepts and quite similar APIs, however not compatible.
Geolocation and geospatial search are hot topics and a lot of people start building web or mobile applications that use it. Companies like Qype are building up databases of points of interest (POIs), which include shops, restaurants etc. With the upcoming HTML5 standard additions, building such applications will be even easier. From this article you will learn: