Arkency Blog

Is it this? http://blog.arkency.com/2016/12/techniques-for-dealing-with-uncertaini… I haven't read it yet, but it looks worthwhile.

Standups can be very useful for entire team. But what bothered us was the sync aspect of it. People knew standup is coming at given hour and they need to schedule their work around it because they know they will be interrupted. So we decided to went with textual async standups on dedicated slack channel. Example: "Yesterday I finished the “fix the price calculator” feature, which was mostly about removing the Coffee code and rely on the value retrieved from the backend, via ajax. The nice thing was that the backend code was already covered with tests, while the Coffee one wasn’t. After that I helped Jack with the “allow logging in with email” feature (we need it now because we have a batch import of users from system X soon). After that I did a small ticket, where I block buying licences for special periods of time. This was nicely TDD'ed, thanks to the concept of aggregate, introduced by Robert recently - all the tests pass < 1s. Here is a commit worth looking at. Today I’m going to start with foreman'ing the recent commits and after that I want to work the XYZ system to allow a better editing of entries. I’m not sure how to start it, so all help is welcome" Blogpost where we describe this technique: http://blog.arkency.com/2014/06/async-standups/ and list of them where we explain the async&remote approach: https://blog.arkency.com/story/async-and-remote/

> The art of turning 6 lines into 92 lines by replacing if-then-else and switch with objects.. > ..In summary, traditional branching is often a student’s tool until a more suitable, polymorphic approach is discovered. I can't tell if this is serious or a straight-faced joke. The article did not convince me at all - in fact it dissuaded me further from the kind of approach taken, which I often encounter in the wild: a class for every condition, with slightly differing implementations. A similarly questionable article was posted a couple days ago: Anti-IF Framework - https://blog.arkency.com/anti-if-framework---if-slash-else-based-on-ty…

I worked on a project with PostgreSQL schemas per tenant (almost like databases). Also worked on another one with "normal" account_id field separation. I documented how they compare in a blogpost: https://blog.arkency.com/comparison-of-approaches-to-multitenancy-in-r… - funnily it was waiting unpublished for some time, stumbling on your post made me finally publish it. Looking forward to go through this comments question and see what others have experienced. I have another draft in the making - about some of the pitfalls of PostgreSQL schemas approach, should be released soon.

If anyone's interested in a more real-life example, then this post presents a Rails controller refactoring from the Redmine project. http://blog.arkency.com/2014/02/rails-refactoring-the-aha-moments/

As in this article. http://blog.arkency.com/2014/02/rails-refactoring-the-aha-moments/ Services should be run with call.

A lot of that, especially points 1-3 depend on if you work with other people synchronously or asynchronously. At my current job we all try to work as much synchronously as possible, so there is no real difference from any other "office job", except everyone is in different location (we all are in roughly the same timezone), and we don't have to commute. We focus on trying to keep sanity, and keep working hours (my experience is that it helps a lot when working remotely) For shops that allow/ or just work asynchronously, other arrangements need to be made to allow that. Usually more and more stuff is written and stored, so everyone can join and leave any moment. There is a similar book being worked on by other ruby-remote working company: Arkency, http://blog.arkency.com/2013/09/arkency-survival-guide-to-effective-pr…