The City: Los Angeles, California
It’s autumn and November is right around the corner! We all know what this means…
Blogging is without a doubt the most important way to get your ideas out to the world, whether your personal take on a recently released album or your professional word on the latest updates to various products from your organization. While social media pushes our concepts out in small bursts, a blog is more of a time tested method for putting our thoughts on record for our users, our readers, and our customers to understand. A blog is still the non-ephemeral placeholder of concepts, and therefore remains a necessary for the modern company.
From time to time our data team gets requests for advice on how to perform cleanup operations against large database tables. Typically, these originate in a ticket requesting information about how the disk is being used or why a specific table is performing poorly.
Somewhat less often, we are asked us to explain why a cleanup attempt has failed or why it has caused downtime for an application. Managing these types of operations with minimal or no downtime can be a challenge given the way a database like MySQL performs these tasks.
The most common form of table cleanup operation we are asked about is for the sessions table. Even though these are not really recommended practice(https://guides.rubyonrails.org/action_controller_overview.html#session) they are still quite common to see. Depending on your application workload and use cases these tables can grow very quickly in size; often including older records that are never going to be used again. Even though the data payload in each row is relatively small, it's not uncommon to find sessions tables that are 10 or 20 GB in size—often larger than the rest of the database combined.
While there is no automatic session cleanup built into a rails app it happens to be really easy to write a rake task that handles this cleanup for you. In fact, it's so easy that it's often overlooked until the table has reached the size where it is difficult to manage
There’s more than one way to build a web application. No matter what type of application you are trying to create, your programmers have their preferred approach and their preferred code languages to accomplish the task. In the world of web applications, most program developers have to decide between Ruby on Rails versus PHP.
Ruby on Rails continues to gain popularity as an effective platform for developing web and cloud applications. Today, there are at least 865,472 business websites running on Ruby on Rails, and the number is growing. Ruby on Rails continues to gain momentum partly because it is open source, which means the developer community continues to improve the platform, and also because Ruby on Rails was created to promote “programmer happiness,” which means programmers are more productive and more efficient developing in Ruby on Rails than on other platforms such as .NET and Java.
Cloud computing has made hosting business-critical applications easier and less expensive. Application hosting makes deploying the resources you need easier and faster—without the overhead of additional hardware, software, and personnel. Once you decide to host your business applications, the question becomes, what criteria do you need to consider when looking for an application hosting provider?
Vue (pronounced as view) calls itself the progressive JavaScript framework. It is designed to be incrementally adoptable. You can use Vue to build user interfaces on a few pages or a few areas of an existing Rails view. You don't have to throw away existing Rails code.
GitHub recently experienced the largest attack we've seen to date. At the peak, they received 1.35 Tbps via 126.9 million packets per second. We don't know who launched the attack but we know how they did it. The attackers used an amplification attack using
This blog post is for Rails developers that want to use Ajax in their application using Unobtrusive JavaScript. This is divided into these parts:
