Topics: Software Development, Testing
So I recently was working on a client project and ran into a problem with an admin report page being super slow only on production, oven though it had russian doll caching setup on it.
Software development has come a long way since the days of punch cards and mainframes. Today, small and medium-sized businesses (SMBs) have more options than ever before when it comes to creating custom software solutions for their needs. In this blog post, we'll explore the evolution of software development, from terminals to clients, and how web-based SaaS has brought us full circle back to terminals.
In the world of SaaS, competition is fierce. Startups and small businesses must constantly strive to stay ahead of the curve and outperform their competitors. But how much better does a SaaS product need to be in order to be competitive?
The answer lies in understanding that different problems can be solved to differing degrees and styles of better. Some solutions are 10x better than the competition, while others may be only 0.1x better, but are different in a way that is significant. For example, a SaaS product may be faster or more intuitive than its competitors. The competition might also be over-serving, providing too many features that customers do not actually need or use.
To illustrate this point, let's take a look at two email marketing automation platforms: Drip.com and ActiveCampaign. Drip.com was a relatively new player in the market, but has quickly gained popularity for its ease of use and automation capabilities. On the other hand, ActiveCampaign was a well-established platform that offers a wide range of features and customization options.
While ActiveCampaign did offer more features than Drip.com, some users found it overwhelming, difficult to use, and expensive. Drip.com, on the other hand, focused on simplicity and automation, making it much easier for users to set up and manage. This difference in approach has allowed Drip.com to differentiate itself from its competitors and gain market share.
So, how do you beat your competition in SaaS? One strategy is to focus on solving a specific problem better than anyone else. This requires a deep understanding of your target audience and their pain points. As startup, you may not have the resources to compete with larger players on all fronts, but you can excel in specific areas.
Hiring a fractional CTO or independent software consultant can also help you identify areas where you can improve and differentiate your product. These experts can provide technical solutions that you may not knowere were possible, letting you quickly iterate and improve your product.
There is no one-size-fits-all answer to how much better a SaaS product needs to be to compete in the market. Different problems require different solutions, and it's up to you to identify areas where you can excel and differentiate your product. By focusing on solving specific problems better than anyone else, and hiring the right expertise, you can quickly scale your SaaS business and gain a competitive advantage.
One of my favourite "magical" characteristics of Ruby on Rails is its naming conventions. We don't need to argue about what the name of the database table that will hold information about a widget should be called, it's widgets. Other frameworks, especially really old ones, didn't do that.
Now, Rails is also great at letting you override and tweaks those options, but really, you almost never need to.
This same convention over configuration mindset continues throughout the framework, even to rendering stuff, which is what we are going to be looking at today.
With Rails, when you pull a record from the database, you can simply call <%= render @widget %> in your view to spit that thing out on the page. But what is it really doing? Well, assuming you haven't changed any defaults, this is going to make a bunch of sane guesses:
@widget is an instance of the Widget class so the partial we are going to use is widgets/_widgetwidgetThis means <%= render @widget %> is effectively <%= render 'widgets/widget', locals: { widget: @widget } %>.
That's a lot of extra code that you just don't need. …unless you do.
I frequently view my widgets in different ways, and have different partials for them:
_widget.html.erb is the full page view_widget_row.html.erb will be used in administrative table views_widget_card.html.erb will be a concise view for use throughout the siteThis means I can't use the simple render call, I need to do one with the partial defined: <%= render 'widgets/widget_row', widget: @widget %>. That's slightly annoying but tolerable. It even works with arrays. Unless you are rendering an array of mixed things: <%= render @things %>. The problem here is that you need to do a different partial for each instance in the array potentially.
Well, I'm not going to let that stop me. Inspired by dom_id(@widget, :specialization) I decided to solve my rendering pain. Adding an additional helper gives me a flexible solution that feels like render and dom_id had a baby. Introducing polymorphic_render:
The third branch is the workhorse of this method. It will wet the partial path to the normal partial path (widgets/widget) and append the suffixes to it. It gets the appropriate name of the instance, and it passes all that to the normal render method.
Basically it does all the manual stuff we normally do, but automatically.
This makes feed rendering code so nice. Instead of some nested monstrosity, its just a simple call to <%= polymorphic_render @feed.items, :feed %> and the correct things/thing_feed partial will be used.
Developers must possess the crucial skill of naming things. Oftentimes, I found myself stuck in a problem until I came across the right name which directly led to a solution. Usually, the root cause of the issue is treating two things as one. Once these things are distinguished, each can serve their respective functions, and the solution will follow.
Custom software can be a game-changer for businesses, providing a tailored solution to their specific needs and challenges. In contrast, no-code solutions are often more limited in their capabilities and may not be able to fully meet the unique requirements of a business. In this blog post, we will explore the benefits of custom software and why it can be better than no-code solutions for businesses.
As a software developer who specializes in custom business solutions, I understand the importance of not only developing software that meets business needs but also maintaining it over time. In this article, I will discuss why software maintenance is crucial, how much it costs, and how long you need to maintain custom software. I will also explore who should maintain the software, what maintenance entails, and the consequences of neglecting it. Additionally, I will touch on the impact of software maintenance on custom business solutions and how the agile methodology supports it.
If you are thinking about making a startup, start with Ruby on Rails. It should be the default. If you disagree with me, you probably know enough that you should ignore my advice. If you don’t, then use RoR and do the right thing.
Startups can be split into 3 technical categories: doesn’t matter, supper critical, and it depends. Yes, you can build your ebook company on a no-code Wordpress plugin. For your blockchain powered AI startup, you already know what you are using. That final category, that one I find super interesting.