Start by removing tinymce-rails-imageupload from your Gemfile and upgrading tinymce-rails to version 6.1.
Make sure you upgrade your tinymce.yml file with the renamed 6.1 plugins and options before you continue.
Test whether TinyMCE still works without the image uploads.
Now replace the uploadimage toolbar button with image and the uploadimage plugin with image in your
tinymce.yml configuration file and add these two options:
images_upload_url: '/tinymce_assets' # for automatic_uploads
images_upload_credentials: true # sends session information with the upload
To avoid some confusion this is the minimum viable tinymce.yml configuration file:
default:
toolbar:
- image
plugins:
- image
images_upload_url: '/tinymce_assets' # for automatic_uploads
images_upload_credentials: true # sends session information with the upload
Note that /tinymce_assets was the default endpoint for tinymce-rails-imageupload POST requests. That controller action
will need a small modification as well. The previous situation was probably something like this:
render json: {
image: {
url: the_url_of_the_upload_here
}
}, content_type: 'text/html'
Replace it with a different JSON object and a normal content type:
render json: { location: the_url_of_the_upload_here }
That’s it, you should now have a nice image upload tab when you click the image button on the toolbar. As a bonus TinyMCE now also supports dragging an image into the editor which will use this endpoint to store it on the server!
Subscribe to the RSS feed to be notified of my next blog post!
]]>I’m talking about the “reader mode”. When available for a website, it is displayed as an icon at the end of the url bar in Firefox. The same is true for Chrome, but you first need to enable it at chrome://flags/#enable-reader-mode. Safari on iOS includes it in the menu at the left of the url bar.
Now open the first example again and click on the reader icon without acknowledging the cookie consent popup. That’s better, right? As an added benefit you get dark mode and typography settings as well.
I believe not a lot of users know about this button, especially because Chrome doesn’t want to show it by default. As you can imagine it’s quite a life saver for informative sites and articles that you just want to read and don’t care about further interacting with.
Subscribe to the RSS feed to be notified of my next blog post!
]]>As you might know, the default Rails system tests use dimensions that are defined in test/application_system_test_case.rb with a line such as:
driven_by :selenium, using: :headless_chrome, screen_size: [1400, 1400]
The most simple solution would be to just modify the sizes in that array. However, this would make all system test cases use the mobile viewport, which is not what I want.
After some searching I found that the Rails APIs did not support setting the screen size for one test case. Capybara, which is used as an underlying gem, does however. So as the first line to a mobile viewport test case you can set the screen size using:
Capybara.current_session.current_window.resize_to(360, 740) # Galaxy S9
The naive solution to resetting the screen size after this test case would be to repeat this call with the original 1400, 1400 as arguments. However, if the test does not succeed, it will not execute that line. It is therefore better to reset the viewport in a seperate teardown method, for example in your test/application_system_test_case.rb file:
teardown do
Capybara.current_session.current_window.resize_to(1400, 1400)
end
You can DRY the resulting test/application_system_test_case.rb a bit by storing the default size in a const array and using that in the various calls. The one I use now looks like this:
# frozen_string_literal: true
require 'test_helper'
class ApplicationSystemTestCase < ActionDispatch::SystemTestCase
WINDOW_SIZE = [1400, 1400].freeze
driven_by :selenium, using: :headless_chrome, screen_size: WINDOW_SIZE
teardown do
Capybara.current_session.current_window.resize_to(*WINDOW_SIZE)
end
end
Subscribe to the RSS feed to be notified of my next blog post!
]]>Another idea was to build a subscription tracking tool. What if some tool could notify me about annual contracts that were about to renew? It would save me money if I wasn’t using that subscription anymore. This would also be useful for small companies, where somebody would sign a contract for a teammate which could renew by accident if the teammate left.
Both launched with a waitlist and had some sign ups, although the video tool sign ups seemed spammy. They were probably not actual prospects. I decided to invest some time in the subscription tracking tool because it was something that scratched my own itch. I had a working product after a few weeks of development and started extending it with expense tracking, because I was also interested in my subscription payment history. While at it, it was not much work to add a manual expense form. You see where this is going? I think it might evolve into a personal finance tool, but lets see how customers start using it.
Speaking about users, how is it doing? When the MVP was ready I launched 3 monthly plans with free trials. Furthermore I launched with one lifetime plan which is only available for the first few months. So far I’ve sold this lifetime plan three times and received numerous monthly plan trial sign ups. The early sign ups were promised a longer trial, so they haven’t reached the point where conversion to paid is required. Lets see in August.
Since I started using Google Ads in month two I received a promotional offer and received almost 200% free credit. I’ve used part of this to promote a project, which seems to work quite well and has resulted in some conversions. New marketing channels I tested were Reddit and Twitter. Twitter didn’t perform that great, although I did have some retweets and obtained a new follower, I don’t think I had sign ups because of my promoted Tweet. Reddit on the other hand worked quite good. I sold some lifetime plans and had some trial sign ups. Although Reddit is probably more expensive, it did have a better efficiency when comparing views vs clicks.
As described above I received quite some signals that a subscription tracker might be a viable product. That is why I decided to sell my api analytics product and focus all my time on a different project. I placed an ad on various marketplaces for SaaS sales and had quite some interesting video and text conversions with possible buyers. After a few weeks I was able to sell it. My company was still in the red up until that point, but selling Callcounter made it profitable for the first time! That is, I’m not able to give myself a salary, but all previous expenses are now covered for as well as some SaaS fees for the coming months.
Quite a rocky period, but in the end my new business is profitable and I’m very motivated to work on my new project. It is much more rewarding to work on a project that has some actual users, I’m looking forward to what the coming month will bring.
Subscribe to the RSS feed to be notified of my next blog post!
]]>Besides using Bing Ads to attract visitors to the website, I also started to do this with Google Ads. Before starting my new business I had a strong objection against this, but this was just the simplest way to get visitors to the site.
This was also the month where I started a blog on the Callcounter domain. I wrote something about Ruby XML serializers there for example, which attracted quite some visitors from Reddit. The total unique visitor count for that post count was somewhere around 200.
I came up with a fun experiment after reading the book Traction: How Any Startup Can Achieve Explosive Customer Growth by Gabriel Weinberg (founder of Duckduckgo) and Justin Mares. To originally grow Duckduckgo Weinberg created a karma widget, with a backlink to his new search engine. In a few hours I created something like that to show of your API usage as well.
To improve conversion rate I switched from having no trial at all, to having a trial which required a credit card. This didn’t result in trial users signups either, so I modified that to a 7 day trial without credit card requirements. So far this has resulted in a number of trial user signups. One of which was just after the “show off your api statistics widget” was published.
Furthermore I added an interactive demo that showcases the Callcounter API statistics itself. Visitors can now interactively see how Callcounter works without creating an account.
This month I also added a live chat solution to the public website. I originally didn’t intend to add one, but the low conversion rates got me doubting the quality of the website. So far I haven’t had the ability to chat with a stranger.
Unfortunately none of the trial users have created a project to actually test Callcounter. Very strange, why would you create an account and then stop there? Creating a project requires just a one field form submission. I’ve asked all trial users, but none have responded. When creating the trial functionality I expected the integration installation to become an obstacle, but none of the trial users have even reached that state.
I’m starting to doubt whether visitors understand why Callcounter could help them. I’m furthering improving texts and images hoping that helps. I’ve achieved quite some things this month though:
Subscribe to the RSS feed to be notified of my next blog post!
]]>Authentication with features like locking, forgot password, remembering sign in.
A much clearer manner of authorizing users when compared to cancan.
Split your application data in “tenants”, which could be seperate customers, domains, etc.
Generate Markdown to HTML.
A template language built by Shopify. Great for customizable webhook implementations for example.
Fast and simple JSON serializer with a simple DSL. See my previous post about JSON serializers.
A very fast and simple xlsx file generator using a C library, that doesn’t consume much memory.
A more extensive xlsx file generatore (pure Ruby). It has more features than fast_excel, but that comes at a cost: slower and more memory usage.
The official Mollie Ruby gem.
The official Stripe Ruby gem.
Mocking and stubbing
Compare hashes and show the differences in a simple language. Great when testing JSON API responses.
Stop execution and start debugging on an interactive console.
Test with real browsers.
Implement an Excel like formula system in your application. Great for giving users some computational data access.
Cocoon implements the frontend parts of nested forms for you.
Read Excelsheets, OpenDocument spreadsheets and csv files.
Linting and other techniques to improve your code quality.
Note that I’ve never built a project with all these gems in it. I always try to keep the dependencies to a minimum to avoid headaches when upgrading gems or the server operating system.
]]>class_names.
Most of us will probably recognize the class name spaghetti that starts to arise when your project grows. Things like this will become littered throughout your views:
<li class="item <%= 'active' if @active %>
<%= 'disabled' if @unpaid_user %>">
Not exactly readable anymore, right? Well, thats what class_names is trying to fix. You just pass it a hash with the class names as keys and conditions as values. Look how nice!
<li class="<%= classs_name item: 1, active: @active, disabled: @unpaid_user ">
You sometimes even need an inline ternary operator:
<li class="<%= @verified_user ? 'verified' : 'unverified' %>">
This can be cleaned up as well:
<li class="<%= class_names verified: @verified, unverified: !@verified %>">
A final improvement might be done by using the tag helper:
tag.li class: class_names(verified: @verified, unverified: !@verified) do
# content
end
The great thing about these helpers is that they are so simple that you can easly backport them to older releases yourself. Something like this in app/helpers/class_names_helper.rb should work on older releases:
module ClassNamesHelper
def build_tag_values(*args)
tag_values = []
args.each do |tag_value|
case tag_value
when Hash
tag_value.each do |key, val|
tag_values << key.to_s if val && key.present?
end
when Array
tag_values.concat build_tag_values(*tag_value)
else
tag_values << tag_value.to_s if tag_value.present?
end
end
tag_values
end
def class_names(*args)
tokens = build_tag_values(*args).flat_map { |value| value.to_s.split(/\s+/) }.uniq
safe_join(tokens, " ")
end
end
Let me know if you found this post useful!
]]>So didn’t I experience any challenges in my first month? Well of course I did experience some challenges, there are lots of new jobs to do! This was the first time I had to actually do marketing, SEO, and advertising.
Having just finished the first minimum viable product version of an analytics product for API providers, I’ve started the marketing and advertising efforts. So far I’ve written some blog posts referencing the product, set up a Twitter account and created a Bing Ads account. Bing Ads you ask? Yes, I had not heard of it either, but apparently it’s Microsoft’s answer to Google Adwords. I’m a huge fan of DuckDuckGo and recently discovered they use Bing Ads for advertising. Given DuckDuckGo’s mission, it’s quite probable that their userbase consists mostly of developers and other possible customer for me. Seems like a great match! I activated my ads a few days ago, but so far I’ve only had 8 impressions. Not enough traffic on DuckDuckGo and Bing? Wrong keywords? I’ll have to experiment some more to find out. The bidding price luckily is not the problem according to the Bing Ads portal.
At my previous job we mostly build marketing sites in WordPress. That was a part I didn’t have much to do with. So for my business I was actually building a marketing site for the first time in years. It should be as accessible for search engines as possible of course. I’ve added noindex to non important pages, I’ve generated a sitemap, added unique title tags to all public pages and written some articles that should give search engines an idea what Callcounter is about.
In this first month I also setup Plausible Analytics to start analysing traffic on the marketing site and this blog. I wanted to protect my visitors privacy when analysing the traffic, so that seemed like a reasonable choice.
Talking to customers was a very important part of running an agency. The big difference was that we could easily meet face to face and mostly worked with customers that we’d know for years. My new business is currently in quite a different situation. The newsletter has some subscribers that I’ve sent emails to. So far not much interaction though. Let’s hope I can improve that in the second month. It’s very important to know what parts are still missing for possible customers or which obstacles they experience. The initial version supports Ruby projects out of the box, because that is what I use myself. I’m hoping to get an idea what kind of integrations possible customers would need. Will it be .NET, Django, Rocket, or …?
The first month summarised in a probably incomplete list:
A short list with the most important tasks I can think of for now:
Subscribe to the RSS feed to be notified of my next blog post!
]]>
=> SELECT date_trunc('hour', created_at),
-> COUNT(*) FROM events GROUP BY 1 LIMIT 10;
date_trunc | count
---------------------+-------
2021-03-22 10:00:00 | 32
2021-03-22 11:00:00 | 92
2021-03-22 13:00:00 | 213
2021-03-22 14:00:00 | 237
2021-03-22 16:00:00 | 331
2021-03-22 17:00:00 | 389
2021-03-22 18:00:00 | 452
2021-03-22 19:00:00 | 493
2021-03-22 20:00:00 | 273
2021-03-22 21:00:00 | 152
(10 rows)
Clearly there is no data for 12:00-13:59 and 15:00-15:59 in the database. Wouldn’t it be great if we can fix this at the database level? That’s where the PostgreSQL generate_series() function comes into play. We can use it to generate a consecutive range of items, which we can then join with our events table.
=> SELECT * FROM generate_series('2021-04-22 10:00'::timestamp,
-> '2021-04-22 21:00', '1 hours');
generate_series
---------------------
2021-04-22 10:00:00
2021-04-22 11:00:00
2021-04-22 12:00:00
2021-04-22 13:00:00
2021-04-22 14:00:00
2021-04-22 15:00:00
2021-04-22 16:00:00
2021-04-22 17:00:00
2021-04-22 18:00:00
2021-04-22 19:00:00
2021-04-22 20:00:00
2021-04-22 21:00:00
(12 rows)
Depending on the ORM you’re using you’ll need to find out how to join this with your events.
]]>We first need to validate that the numbers we store are actually unique. Validations in Ruby have some race conditions, where two might be generated at the same time without either one noticing. So, there is only one place where you can be sure of uniqueness: in the database. I’ve added a unique index on the invoice number column to fail hard if something might generate a duplicate.
add_index :invoices, :number, unique: true
Next we need to build the actual generation of unique numbers. I’ve chosen to build an InvoiceService which is responsible for creating invoices and generating unique numbers. The numbers are in the format of year-number, for example 2021-123. For this I’ve made a function that that looks up the previous invoice number parts. Something like this works:
def last_invoice_number_parts
current_year = Time.zone.now.year.to_s
last_invoice = Invoice.order(Arel.sql('substring(number from 6)::int')).last
if last_invoice&.number&.start_with?(current_year)
last_invoice.number.split('-')
else
[current_year, 0]
end
end
Now the tricky part, how do we generate a new number and make sure it’s unique when stored? Regenerate and save again when you catch the ActiveRecord::RecordNotUnique exception on save. If that happens it means we need to generate a new incremented number and should thus try again. Something like this should work:
def generate_invoice_number
parts = last_invoice_number_parts
@invoice.number = "#{parts.first}-#{parts.last.to_i + 1}"
@invoice.save!
rescue ActiveRecord::RecordNotUnique
retry # another database record was just with the same number
end
That’s it. Let’s hope this function will generate a lot of unique invoice numbers for us!
]]>