Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • kmitov 9:09 am on March 11, 2020 Permalink |
    Tags: awesome, , ,   

    They will leave you, if they tell you everything is fine – [Everyday Company Culture] 

    Culture is how we do stuff around here. Read more about the [Everyday Company Culture] series.

    Today’s resolution. TL;DR

    If team members tell you everything is fine, it’s like a sure sign they will leave you.

    Today’s case

    People leave your organization for different reasons. One pattern I’ve noticed, learned and observed through the years is that people leave when “everything is fine” and people stay when there is a “list of things that are wrong”. People stay for “something” to fight for, because “something” is not right. People don’t stay because “everything is awesome”.

    As a manager be careful when team members return a positive feedback. Of course you want a positive feedback and you want people to be happy. But this does not mean there are no things to work towards to. Get feedback constantly, list things that are still not OK and work towards improving and resolving them.

    Root cause

    “Everything is fine” could mean that people don’t care enough to point the problems.

    Full story

    A team member of our organization left us yesterday. He was a great guy with great potential. As a software product company we are working on developing frameworks and solutions and this requires a great set of skills. It is certainly not a regular software development job. We are the ones building the platforms and the frameworks and providing them to clients and other developers. My experience is that not many people could grasp the concepts, importance and rules when building things like a sustainable API. This guy did, but he left us yesterday as he wanted to explore a different career path. (yek, this is more corporate sounding that I am comfortable with, but you get the point)

    Anyway, this finally prompt me to write this article and get deeper into. I hope members in and out of our organization could benefit by identifying and approaching such cases. Looking even at my personal experience as I have left two companies in my career, I did left when everything was kind of ok.

    Feedback and retrospective is a must

    We do regular retrospectives and I try to get more formalized feedback from team members. This happens once every 1-2 months with a simple Trello card where everybody should answer a few simple questions like:

    1. What are we doing wrong
    2. What are we doing right
    3. What could we improve

    Team members answer these questions publicly or privately to their managers.

    We are also doing regular 1-on-1 discussions (because we are not doing meetings…) and talk about how our organization is doing. The means of receiving feedback could be different, but it is important to give and receive feedback regularly. Even on a daily basis. Of course, you don’t have to solve every issue over lunch, but you could take a note (literally take a note and write it down) if in a conversation someone is mentioning that they have a “problem with something”. After all your job is to address this.

    On these regular retrospectives I try to be the first to return feedback and be honest of where we are, what have we done and what we could improve.

    67 things we could improve – co-founder

    On one of this discussions we sat down with my co-founder and we started sharing all the things that we don’t like. We wrote them down. Every one of them. One of them was of course “we should make more money”. But the others 66 were basically not connected with money at all and were rather small things in the whole organization. So we were happy that we have a basics right and in the large picture we are ok and moving in the right direction. But there were 66 things we came up with in about an hour that we thing we should improve.

    Example – one of them was “more A/B testing” before taking decisions. Since then we have done about 15 different tests that help us learned more and we are doing more structured A/B testing. Yet still, if currently we have to list the things that we could improve “more A/B testing” would make it to the list as there are still some decisions that we make based on a “feeling, preference and common sense”, which could be correct, but are not based on data.

    Point is – there are still things we could improve and we want to improve and we want to stay for.

    ‘I am a problem’ – VP of Engineering

    I’ve constantly received feedback from our VP of Engineering. He is sharing it publicly to the whole team and is somewhere on the lines of “I think that the organization is great, but It seems that I am not doing enough and I am trying to change this,…”. Here again – other things are great, of course we could always get more clients, but it is “me that is not doing enough and I am working on fixing this”. There are few things better than hearing your VP of Engineering, that has the largest engineering experience than any other in the organization, come to the office and say “Yesterday I learned how we could do this thing x2 times faster”

    ‘Our code needs to improve’

    As a software company we are working on our code. In one of our latest products we have one of the most clean code that I’ve ever seen. We could deliver in minutes. Modularity is great. Concerns are separated. Almost no redundancy and coupling. Automatic tests for different modules run in seconds. It is just really fun.

    Yet I’ve constantly received feedback that “our code needs to improve”. Because there is always room for improvement. This tests that are running for 15 seconds could now run for 5. This class could be renamed to make it more clear. This method could be called with different params and refactored. And the code could be made even more beautiful. We have a backlog of about 81 things that are exactly this. Not features, but just things to improve and make even better. So we prioritize and work on them in order. As we work we would learn more and the backlog grows even further and that’s ok.

    Point is, there are things that we are working towards to in the code. The code is never fine.

    “Everything is OK” and why at least ONE thing is not OK.

    Compare the above three examples with an “Everything is fine” feedback. No, it is not fine. It can never be fine. You could be doing too much meetings. Probably you are. Or sending to much emails. Probably you are. You could have unclear responsibilities. You could have people on positions that are not appropriate for them.

    Again, the point is that even if everything else in your organization is fine internally, even if you are the greatest “leader of all times”, even when people are earning enough, there is one thing that is still not fine. This thing is the reason your organization exist and the reason you’ve gathered your team. In our case – “people get confused and feel a lot of frustration when they don’t have an easy to follow 3D assembly instructions available instantly on their device”. This is the reason we are developing our products. After all, you’ve gathered together as a team to tackle a problem and even if everything else is “OK”, it is still not OK that there are people feeling pain and in need of your medicine.

  • kmitov 7:47 am on February 21, 2020 Permalink |
    Tags: , ,   

    Feedback could come in any form, not just the one that makes it easy to accept it – [Everyday Company Culture] 

    Culture is how we do stuff around here. Read more about the [Everyday Company Culture] series.

    Today’s resolution. TL;DR

    Feedback from the team could be returned in any form, not only formally, not only verbally, not explicitly, but by the day to day mistakes that we make. Accept all kinds of feedback. Don’t be a “douchebag”.

    Today’s case

    There was a requirement for everybody to write the text “Result” as a first line in the comment of his/her work when marking a task as completed. People were following the rule, but writing “reuslt”, “results”, “Done:”, “Restult”, “Release:” and many others, but were not writing “Result”.

    Instead of pushing for everybody to use the right “Result” at the end we ended up with a list of possible “results” that team members could write as the first line of their result description. It turn out to be pretty funny to add new results and as of today this is the list of all the possible values, accepted by the platform.

    possible_results = ["result", 
      "result:", "results:", #These are added because of Ivan
      "blabla result", 
      "result blabla", 
      "Special Result Line", 
      "The Result:", 
      "Take this result Kiril, I hope you are having a great time",
      "Resutl", # this one is added because of Mihail
      "Restult", # this one is added because of Mihail
      "Ready:", # this one is added because of Mitaka
      "Ready", # this one is added because of Mitaka
      "Done:", # this one is added because of Aleks
      "Done", # This one is added because of Aleks

    These results are accepted in any form of case – upper and lower. We have a team member that submits his results as:

    TaKe ThIs ReSuLt KiRiL, i HoPe YoU aRe HaViNg A gReAt TiMe

    Which is arguably, very funny.

    Root cause

    Feedback was not accepted. 

    We as a team all accepted that we should have “Result” of the work and we should have a description what is actually the result. Generally the result is different from the goals of the task. The goal is “develop a feature”. But the result is “visit this URL to see the feature”.

    We were just making mistakes when marking the result and I was pushing for the use of the correct word which is:”Result”. Nobody returned an explicit, verbal feedback – “I think we should make the result with ‘Done:’, because I don’t like writing ‘Result:'”. Nobody said this. We all understood that there should be a rule and we should follow the rule. But we were just making mistakes.

    Full Story

    I was trying to establish a rule in the team – when a piece of “work” is completed you must provide a short description, URL link, commit, picture/video of the new feature. This makes it extremely easy to generate release notes that we make public to the client. Only rule was

    “When you submit your the description of the result the text must start with ‘Result’.

    Something like this will be enough


    We have implemented a new feature that shows a progress bar when downloading the assembly instruction.

    Here is how it looks like

    After the result is provided we use different internal tools and I could easily generate public client Release Notes for our products and platforms. Examples at: or

    Sounds easy. Only thing you have to do is start your description with “Result”, because other values could be “time track:”, “Code Review”, etc. It took me weeks before I finally realize that we should not be strict on the value “Result”. We should be strict on the behavior that everybody should write a result, but if you happen to make a mistake and write “resTult” – that should not be a problem. We got you on the platform end, accepting different input values for result. Does not matter how you call it, as long as it is there.

  • kmitov 6:34 am on February 21, 2020 Permalink |
    Tags: ,   

    Everyday Company Culture – what’s it about 

    Culture is how we do stuff around here. Every day there is a new challenge with communication, transparency, accountability, with what we value and what we think of the world (mainly inside of our organization).

    With the Everyday Company Culture series I am trying to look at specific cases, the root cause of the challenge and how we approach them. This approach is different form setting X high level, single word values that are understood differently by each member in organization. Example – transparency. It is easy to aim for a ‘transparency’ in an organization. It is difficult to properly communicate what is ‘transparency’. Same for ‘diversity’, ‘accountability’, ‘clarity in communication’, etc.

    My hope is that this series could bring more value inside of our organization and hopefully help other small and large teams work better.

    Check out the full series at

  • kmitov 7:17 am on February 19, 2020 Permalink |
    Tags: communication, , team   

    Why you should make little assumptions on what team members have understood – [Everyday Company Culture] 

    Culture is how we do stuff around here. Every day there is a new challenge with communication, transparency, accountability, with what we value and what we think of the world (mainly inside of our organization).

    With the Everyday Company Culture series I am trying to look at specific cases, the root cause of the challenge and how we approach them. This approach is different form setting X high level, single word values that are understood differently by each member in organization. Example – transparency. It is easy to aim for a ‘transparency’ in an organization. It is difficult to properly communicate what is ‘transparency’. Same for ‘diversity’, ‘accountability’, ‘clarity in communication’, etc.

    My hope is that this series could bring more value inside of our organization and hopefully help other small and large teams work better.

    Today’s resolution. TL;DR

    Don’t assume that people know. Ask for confirmation especially when things seem trivial to you. If things are not trivial you would have spend time to properly communicate them. But when things are trivial from your point of view you could make a large assumption that they are also trivial for others.

    Today’s case

    “A Robotics field that costs about 150 euros and 2 days to assemble is lost and it would take about $500 and 2 days now to restore it”

    Root cause

    Assumption. Communication.

    We made a wrong assumption that a new team member understands a term that we’ve been using in our team for the last 7 years. We as a team made the assumption that the new member is familiar with how things are done in our team. We’ve never been explicit and even though about being explicit about this specific topic.

    Full Story

    Ivo is part of the team for about 1 year. He was using a robotics field for a project he has been working and has already completed. The field has about 15 models placed on it. Ivo is asked a few times by the rest of the team “When is he going to disassemble the field, because it takes a lot of space. He is currently not using it and won’t be using it in the near future”.

    The end result is that he disassembles the field and he also disassembles the models on the field. But he should have just disassembled the field. Not the models.

    The challenge was that for the last 7 years the term “disassemble the field” in the team has grown to mean something different from what a relatively new team member will understand. We as a team made an assumption that Ivo will distinguish between “disassemble the field” and “disassemble the models”. For Ivo on the other hand the term “disassemble the field” means “disassemble both the field and the models”

    Nobody on the team could imagine that we should be explicit about this and ask Ivo to differentiate between them. As a result we’ve lost about 4 days of work and about $700. It would be cheaper to buy new models than to try to assemble again the disassembled models.

  • kmitov 6:48 am on August 12, 2019 Permalink |
    Tags: , , ,   

    ‘if-else’ is Forbidden – why and how to reduce logic branching in your code. 

    Each time there is an if-else logic in your code there is some logic branching. A state is checked and based on the result from the check different path are taken. This means that two scenarios are implemented and two scenarios should be support from now on. This could quickly become a problem because the number of supported cases grows exponentially.

    The more decisions you make in the code the more cases you must support.

    At the end you start from Process1 but you have 4 different cases and path that you should support. These are 4 different tests that should be written and these are for different places where things could go wrong.

    The four different paths are Process 1,2,4; 1,2,5; 1,3,6; 1,3,7

    Demonstration of a live example and a real production bug

    We have Subscriptions in the platform. Each subscription has a max_users field that shows how many users you could add to this subscription. If max_users=1 this means you can have only one user using the subscription.

    When adding people to the subscription you have two cases

    1. You successfully add someone to the subscription and you show a message “Success”
    2. The max users is reached and you show a message “Error”

    The code in a simplified manner looks something like this:

       form.show_message "Success"
       form.show_message "Error"

    While developing we’ve changed the code for the error from form.show_message “Error” to modal_dialog.show_message “Error”

    After that we’ve changed the implementation further and the code for modal_dialog.show_message “Error” was no longed called.

    As a result when the use tries to add someone to his subscription, for which they’ve payed, the app freezes and nothing happens. There is no error displayed and no user is added to the subscription.

    The bug occurred because with the latest changes we’ve forgot to manually check the second case of the if-else clause and there is was not test developed for this case.

    How to remove the if-else clause from this code
    message = subscription.get_save_message
    form.show_message message

    The knows what message to set based on whether the subscription was successfully saved. It could set Error or it could set Success. After that we just show whatever message the subscription has to the form. If it is empty that’s great. This means no errors have occurred. subscriptions.get_save_message could be implemented in many different ways. It could be on the subscription object or another object, but this depends on the technology and framework used. But after the method save is called the message is set and there is a single flow and now branches in our code. The method form.show_message is called a single time on a single place in our code. If we change the API of this method we would change in a single place and will not forget about the second place. There is always a single scenario. Save->Show message.

  • kmitov 7:06 am on January 22, 2019 Permalink |
    Tags: cache, ,   

    Implementation of Multi-levels caching. Example for Rails 

    There are two difficult things in Computer Science. Choosing a name for a variable and cache invalidation.

    That being said I went on a journey to implement multi-levels caching in one of our platforms. Cache should be fast. Fast cache is expensive. If you can use 1M of very fast and expensive cache, why not implement a second level cache that is 10M, not that fast and not that expensive and 100M of normal cache that is cheap, but still faster than going to db.


    I decided to implement a DbCache that will store cached html rendered values directly in db and will access them from the DB instead of the fast Redis/Memcachier cache. All in the name of saving a few dollars on expensive fast cache that I do not really need.

    <% cache(cache_key) do # this is the redis cache %>
      <%= db_cache(cache_key) do # this is the db cache %>
        <% # actual calculation of value %>
      <% end %>
    <% end %>


    There is no need to constantly render the html/json of the content that we would like to serve to the client. It could be rendered once and served until updated. We are using Memcachier for a very fast access to cached values, but it is costing us more money. And in many cases we do not need this fast access.

    That’s why there is a DbCache implementation

    It works in the following way. It has a key and a value.

    When using in the view you can use

     <% cache(cache_key) do %>
       <%= db_cache(cache_key) do %>
       <% end %>
     <% end %>

    In this way if something is in cache we take it. This is L1 cache if you like. If it is not in L1 cache (that is stored in memory) than we ask db_cache. db_cache is our second level cache – L2. If the value is not in db_cache then we render it. The principle could be applied for L3 cache, although we are not there yet as a platform to need L3 cache.

    But it is db_cache. It is accessing the db. Why do you even call it cache?

    When the db_cache is accessed we make a single query to the db and retrieve a single record. For an indexed, not very large table this is fast. If the value is to be rendered again it will mean making a few more request for different objects and their associations and moving through all the trouble of rendering it again which involves views. By retrieving the HTML/JSON directly from DB we could directly serve it.

    How is db_cache implemented?

    DbCache model that stores the values in the db. It has a key and value columns. That’s it. Creating/retrieving/updating DbCache records is what is interesting.

    The key is column in the DB that is an integer. NOT a string. This integer is generated with a hash function and is than shifted right. The postgres db has a signed int column and the hash is generating an unsigned int. We have to shift because there is not enough space for storing unsigned int in a postgres db. In this way the cache key given from the developer is transformed to an internal key that is used for finding the record. And there of course is an index on this hash64 column.

    def db_cache key, &block
      # This will give us a 64 bit hash
      # Shift the value to reduce it because the column is signed and there is no room for
      # an unsigned value
      internal_key = Digest::XXH64.hexdigest(key).to_i(16) >> 1
      db_cache = DbCache.find_by(hash64: internal_key)

    How are keys expired?

    If a key has expired we must create a new record for this key. Expiring keys could be difficult. Every record has an updated_at value. Every day a job on the db is run and if the updated_at value is more than specific days old it is automatically expired. This controls the number of records in the DB. I am kind of interested in storing only records that are regularly accessed. I think that if a page was not accessed in a couple of days, you generally do not need a cached value for it.

    This opens the next question:

    How are keys marked not to expire? If we change the accessed_at for a record on every read that will be slow because of a write to accessed_at

    True. It is important to expire old keys, but it is also important not to touch records on every read request because this will be very slow. If we make a touch on every request to the cache this will involve an update that will slow down the method. So an update is happening only once a day. See the db_cache.touch call below. The record could be accessed thousands of times today but there will be only one write to update the updated_at value. To touch the record.

    def db_cache key, &block
      internal_key = Digest::XXH64.hexdigest(key).to_i(16) >> 1
      db_cache = DbCache.find_by(hash64: internal_key)
      if db_cache.nil?
        # create cache value
        db_cache.touch if db_cache.updated_at < -

    How fast is DbCache?

    These are just referenced values and of course this depends on the size of your cached values and the db and the load. In our specific case on Heroku we’ve found that the DbCache generally retrieves values in the range of 2 to 8 ms. In comparison the very fast Memcachier does this in the range of 2 to 8 ms.

    We also used NewRelic to look at the performance that end users are experiencing. And there was a large improvement because we could cache hundreds of MB of records in DB compared to the few MB for Memcachier that we are paying for.

    Rails specific details

    Since this code has to live in our platform and it is also bound to use some other rails object there are a few things more that I’ve done. Here is the full code that I hope gives a complete picture.

    # Author::    Kiril Mitov  
    # Copyright:: Copyright (c) 2018 Robopartans Group
    # License::   MIT
    module DbCacheHelper
      def db_cache key, &block
        # puts "db_cache: key: #{key}"
        result = nil
        if controller.respond_to?(:perform_caching) && controller.perform_caching
          # This will give us a 64 bit hash
          # Shift the value to reduce it because the column is signed and there is now room for
          # un unsigned value
          internal_key = Digest::XXH64.hexdigest(key).to_i(16) >> 1
          db_cache = DbCache.find_by(hash64: internal_key)
          if db_cache.nil?
            # puts "DBCache Miss: #{key}, #{internal_key}"
   "DBCache Miss: #{key}, #{internal_key}"
            content = capture(&block)
            # Use a rescue. This will make sure that if
            # a race condition occurs between the check for
            # existence of the db_cache and the actuall write
            # we will still be able to find the key.
            # This happens when two or more people access the site at exactly the
            # same time.
              # puts "DBCache: Trying to create"
              # puts "DBCache Count before find or create: #{DbCache.count}"
              db_cache = DbCache.find_or_create_by(hash64: internal_key)
              # puts "DBCache Count after find or create: #{DbCache.count}"
              # puts "DBCache: Found or record is with id:#{}"
            rescue ActiveRecord::RecordNotUnique
            # The update is after the create because the value should not be part of the
            # create.
            db_cache.update(value: content)
            # puts "DBCache Hit: #{key}, #{internal_key}"
   "DBCache Hit: #{key}, #{internal_key}"
            db_cache.touch if db_cache.updated_at < -
          result = db_cache.value
          result = capture(&block)
        # Result could be nil if we've cached nil. So just dont return nil,
        # but return empty string
        result ? result.html_safe : ""

  • kmitov 2:02 pm on January 9, 2019 Permalink |
    Tags: i18n, parallel, , ,   

    i18n locales and the pass of rspec parallel specs and 

    First rule of good unit testing is: each test should be independent of the other tests.

    But if there is a global variable like I18n.locale than one spec could touch it and another spec will be run in a different locale from the default.


    Before each suite of specs set the locale to the default. This ensures that the specs are run against the same locale each time. Specific code is:

    # spec/rails_helper.rb
    RSpec.configure do |config|
      config.before :each do
        I18n.locale = Globalize.locale = I18n.default_locale

    i18n breaks spec isolation

    Internationalization, or i18n, should be part of most platforms. This means that i18n features should be properly tests. In suites when one of the specs modifies i18n the specs that are run after that are dependent on this new local.

    This seem trivial, but we only go to explore it the moment we started running specs in parallel on different CPU cores. The specs were started and run in different times and order on each run.

  • kmitov 7:21 am on January 8, 2019 Permalink |
    Tags: capybara, chromedriver, feature tests, google-chrome, , , ,   

    Chromedriver not filling all the whole password field in automated RSpec, Capybara, Feature Tests 

    This is such a lovely story. You will like it.

    When using google chromedriver to run capybara tests sometimes, just sometimes, especially if the tests are run in parallel, when the test has to fill a text field like a password, it fills only part of it. Last time checked for chromedriver 2.45

    TL; DR;

    Solution – google does not care, or it seems it is too difficult for the chromedriver team to resolve so there simply is no solution.

    What is the test?

    We are using Rails, Rspec, Capybara, Google chromedriver. We are developing feature tests. Tests are run in parallel with

    rake parallel:spec

    Here is the test in question. Simply fill a password on the form for upgrading a subscription, click on Confirm and expect to be redirected to a page that says – “You’ve upgraded your subscription”

    def submit_and_expect_success password
          # dialog opens to confirm with password
          fill_in "owner_password", with: password
          click_on "Confirm"
          expect_redirect_to "/subscriptions/#{subscription.to_param}"
          # If it redirects to this page, it means that the change was successful
          expect(page).to have_current_path "/subscriptions/#{subscription.to_param}"

    And the tests are failing with timeout at expect_redirect_to. No, expect_redirect_to is a custom method, because we are using ActionCable to wait for subscription upgrade to finish. Because of the payment service at the back this sometimes takes a while and we want to show a nice progress and we need a websocket. But that being said the method is nothing special.

    module ExpectRedirect
      def expect_redirect_to url
        # If the path doesn't change before the timeout passes,
        # the test will fail, because there will be no redirect
        puts "expect url: #{url}"
          Timeout.timeout(Capybara.default_max_wait_time) do
            sleep(0.1) until url == URI(page.current_url).path
        rescue Timeout::Error=>e
          puts "Current url is still: #{page.current_url}"
          puts page.body
          raise e

    If we are redirected to the url withing Capybara.default_max_wait_time than everything is fine. If not, we are raising the Timeout::Error.

    Parallel execution

    For some reason the test in question fails only when we are doing a parallel execution. Or at least mostly when we are doing parallel execution of the tests. So we moved through some nice articles to revise our understanding of Timeout again and again.

    But nevertheless the tests were failing with Timeout::Error on waiting for a redirect and in the html we could see the error returned by the server:

    <div><p>Invalid password</p></div>

    How come the password is Invalid

    No this took a while to debug and it seems rather mysterious but this is what we got:

    User password in DB is: 10124ddeaf1a69e3748e308508d916b6

    The server receives from the html form: 10124ddeaf1a69e3748e30850

    User password in DB is: 74c2a3e926420e1a30363423f121fc1e

    The server receives from the html from: 74c2a3e926420e1a3

    and so on and so on.

    Sometimes the difference is 8 symbols. Sometimes it is 2. Sometimes it is 16.

    It seems to be a client side issue

    Like. JavaScript. If there is an error this strange it has to be in the JavaScript. Right. There in the javascript we see:

    let form_data = form.serializeObject();
    this.perform('start_change', form_data);

    The form gets serialized. Probably it is not serialized correctly. Probably the values that we are sending are just not the values on the form. So I revised my knowledge on serializing objects in JavaScript with

    So far so good. But the serialization was not the problem. Here is what I did. I fixed all the passwords to be 32 symbols.

    let form_data = form.serializeObject();
     if(form_data["owner_password"].lenght != 32) {
            form_data["owner_password"] = "this was:" + form_data["owner_password"] + " which is less than 32 symbols"
    this.perform('start_change', form_data);

    It it happened. The value of the password field was simply not 32 symbols long. It was not filled during the test.

    A little bit of search and we arrive at:

    and there in the bottom of the issue, there is the standard: “Not our problem resolution” with the link to:

    It seems that google chromedriver is not filling all the characters in the password field. It is doing it on random and is completely unpredictable.

    Issue still exists on:

    Issue still exist for
    Chrome: Version 71.0.3578.98 (Official Build) (64-bit)
    Chromedriver chromedriver --version
    ChromeDriver 2.45.615279 (12b89733300bd268cff3b78fc76cb8f3a7cc44e5)
    Linux kireto-laptop3 4.4.0-141-generic #167-Ubuntu x86_64 GNU/Linux
    Description:	Ubuntu 16.04.5 LTS
    Release:	16.04
    Codename:	xenial

    Today we would try Firefox driver.

  • kmitov 6:00 pm on January 3, 2019 Permalink |
    Tags: http,   

    The curious case of …http status code 505 

    Today I learned that there was such a thing as http status code 505. Well, I’ve been in software development for quite some time, but 505 was a new for me.

    TL; DR;

    There was a space in the URL and this results in an error 505


    The curious case started with an error when we were checking that some links on the platform are valid. This is what happened:

    Message: "Error: The link returned status code 505! 
    Error: The link returned status code 505! 
    Error: The link returned status code 505! 
    Error: The link returned status code 505! "

    Strange. A quick curl revealed that the url was correct and curl was returning a correct result. wget also showed that it is working.

    It took me about one hour. One hour looking and the problem was the following:

    When the HTML document was constructed it had the following content

    <a href="{{ competitions_link }} "><img..

    Note the space. The space after }} and before “. The space right here <a href=”{{ competitions_link }}HERE”>. This took an hour today. And the solution is just to strip.


    If interested here is the test for this problem:

    it "strips url and then checks them to avoid error 505" do
         link = ' '
    stub_request(:head, "").to_return(status: 201)
    success, message = UrlChecker::check_link link, true
    expect(success).to be_truthy
    expect(message).to be_empty

  • kmitov 10:02 am on December 31, 2018 Permalink |
    Tags: , Software Planning, Trello   

    How to plan with Trello? Part 1 – backlog and sprint board 

    I recently shared this with a friend that is constantly getting lost with Trello and how exactly to structure his software project plan. I shared my experience with him and he kind of liked it so here is my story and the few rules that are keeping me sane for the past 2 years of following them.

    Main issues with planing a software project with Trello is to decide

    • are different features in different board,
    • why do you need lables. Are different features marked with labels
    • are different features in lists?
    • how do you set the priority for a task. Do you have a list for priority, or label for priority.

    Because of these questions for the last 4-5-6 years I’ve started and stopped using Trello many times.

    These are all difficult questions. Here are my simple solutions.


    Create two boards. Backlog and SprintXX. In the SprintXX you have three lists. XX is the number of the sprint. “SPXX Planned“, “Ongoing“, “Done SPXX December 01- December 15“. When the sprint that is two – three weeks finishes you archive “Done SPXX December 01- December 15” and create a new “Done SPXX+1 December 16-December 31” list. Then you rename list “SPXX Planned” to “SPXX+1 Planned” where XX is the number of the Sprint.

    This keeps the Trello clear.

    Create two boards

    Board one is the Sprint board
    Board two is the Backlog board

    If you are currently not working on the task and there is little to no chance to work on it in the next 3-4 weeks that it is in the Backlog. This means it will be handled later.

    Sprint Board

    The Sprint board has the name of the current Sprint. I like sprints that are 2-3 weeks long. It has three lists

    SPXX Planed

    The list has all the tasks that are planned for the current sprint or probably the next one. These are tasks that you are genuinely planning to do something about.


    These are all the tasks that we are currently working on. If we have even a single line of code for this task than we are working on it.

    Done SPXX December 01 – December 15

    These are all the tasks completed in the spring XX. Note that the list has the name “Done SPXX December 01 – December 15”. This is the full name of the sprint.

    At the end of the sprint

    When the spring ends you archive “Done SPXX December 01 -December 15”. You do not archive the tasks. You archive the whole list. This gives you a chance to get back to the list at the regular reviews that you are having with the team and actually review what has happened in this sprint.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc