October 1, 2018

Mongo security

Sooner or later it is unevitable to secure your database. At least in my opinion... It was the first time I was securing a MongoDB instance and when I was looking for some information I came across this blog post. At first, if you want to set up username&password authentication for your MongoDB instance, you will find the article really helpful. Secondly, you can take much more from the post...specifically almost 600TB of data from all around the world (if you wish of course).

MongoDB security

So...I promised a remarkably big bundle of data. Good news is it is as easy as copypasting a command to your console to get it...if you have 600TBs of storage space. If you want to try this out, just read this analysis mentioned in the blog referenced above. The bad news is that probably almost none of those hundreds of whatever bytes out there are publicly accessible intentionally. This data comes from more than 30 000 completely unsecured MongoDB instances. It is natural to ask for a reason - so why is it that this big number of MongoDB instances serves data to just anyone who asks for it?

At first, it is important to note that 30 000 IS a big number. The main reason behind this global security neglection is simple - for a fairly long time, default MongoDB configuration was left completely unsecured.

Security is usually the first argument against using Mongo and it has been heavily criticised in that field (especially after a lovely global ransomware attack. But MongoDB developers are definitely not the only ones in charge for the situation - in fact, those 30 000 instances is how 'nah, it'll be OK' looks like - thousands of people just didn't want to spend a while configuring even a simple authentication mechanism. Simply the idea that your data is safe because it is not any kind of top secret information with a little bit of natural human laziness grant results (almost 600TBs of results).

After I realised how simple it is to provide the basic authentication settings I was just wondering why so many people haven't done these simple steps. In my opinion the biggest problem with data security is the perception of data - sadly not everyone sees it as something valuable nowadays...but as I would not leave alone my wallet or phone I would not do the same with data. The second important factor is our human nature - everyone has this 'nah, it'll be OK' in them. For me the most important message is that setting up at least username&password authentication for your MongoDB is a small step for a developer, but a huge leap for the security of your data.

Our team

September 17, 2018

Scrum Master isn’t Scrum

I just recently saw someone joking about Scrum on the Twitter. He wasn't very fond of Scrum because by his own words, "What kind of methodology is it, when it needs a single dedicated person to enforce it?" We are talking about Scrum Master role here. I'm having many problems with this statement.

First things first, we need to specify the size of company we are talking about. Sure, a massive company needs a dedicated person in a same way as, for example, an HR role. Or someone who is responsible only for marketing (hi Veronika). If you can justify having dedicated Project Manager, having a dedicated Scrum Master is hardly an issue and it shouldn't be held against Scrum.

But let's say we are talking about a small company, maybe even a startup. You absolutely don't need a dedicated person, it can be someone from your team. It's not that there is a sharp border between your coders and Scrum Master which is doing Scrum. Your whole team should do the Scrum. The Scrum Master is just an element which lowers the friction between Product Owner and rest of the team. Which makes sure sub-tasks are moving smoothly through sprint and no one is stuck for too long with one. Which can say no to adding more features to already started sprint. But if the team itself is apathetic to daily stand-ups and Scrum Master has to enforce them every time, you aren't doing Scrum right then.
From time to time, I hear negative things about Scrum but it usually boils down to three problems.

  • You're enforcing Scrum even though you don't really need a Scrum
  • You treat Scrum as a religion which cannot be even slightly bend to your needs
  • You bend Scrum so much to the point it's not even Scrum


The last point is actually pretty usual. Someone heard Scrum is "the thing" so the company switched to this methodology. On the surface level. Team is probably doing all types of meetings but new stories are added to the sprint when Product Owner tells without any estimation. Backlog is planned at the start of the project and is treated as sacred relic during the project lifespan. And project manager is complaining the Scrum doesn't work. No wonder when you do waterfall under the hood.

If you happen to be from Czech Republic and this kind of situation is familiar to you or even when you're still at the university and want experience the real development process with Scrum, consider visiting our FeelScrum workshop. There are many misconceptions about Scrum we will address and you will also be able to try the development process with commonly used tools like Jira, Confluence or Jenkins.

This short article features 23 mentions of word Scrum. I'm so sorry about that 🙂

Our team

August 24, 2018

Continuous Integration (CI)

Let's face the Continuous Integration the development practice that requires developers to integrate code into a shared repository at least once a day per developer. Each check-in is then verified by an automated build, allowing teams to detect problems early. The "continuous" has meaning of regular work, like that you can detect errors quickly, locate them more easily and remove.

Also, it is about verifying if the new code you just wrote broke or not the code that was already working, since the automated tests and other tasks (like syntax verification) are executed when integrating the code. You can't, however expect continuous Integration to get rid of bugs.

Another very important thing when talking about CI is that it needs to be supported by a suite of automated tests (not only unit tests, but also by integration tests, and even better, if possible, by end-to-end tests)

The best part is that continuous Integration is cheap. Not integrating continuously is expensive. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous integration is composed of some essential tasks as Matthew Setter talks about it. you can look them up, but I would like to have a look at the most critical one's.

Make your build self-testing
A self-testing process is the kernel of continuous integration. The build has tests that validate the software. No matter whether you use BDD (Behavior Driven Development), TDD (Test Driven Development), or any of the other xDD’s, testing needs to be front and center in the build process.

Automate the build
Automating the build builds on the fact that it is self-testing. You have the tests in place, now make sure they are run every time. This is a natural complement to software validation.

Make it transparent
The software’s tested before it’s deployed. The deployment happens the same way every time.

Test in a clone of the production environment
This highlights a challenge that has plagued web-based applications for some time. Speaking from personal experience, whether developers develop on Linux, use OSX, or Windows, they usually host on Linux. Even when we develop on the same platform, we may not consider library versions, the existence of extensions, or the extensions’ versions, which can cause problems. So many things can go wrong after the application’s deployed.

Make it easy for anyone to get the latest executable
No matter whether it’s a senior or junior developer, whether it’s a long-term employee or someone brand new to the company, getting a working build of the latest copy of the application or service should be child’s play.

CI is not just a development practice by itself, it has also meaning for being competitive in the market,. It is very good, if you can launch new features that matters for your users faster than your competitors, so you can have advantage and better time to market. Then, CI allows you also to do another very important task from these days, that is called continuous delivery.

Our team

August 22, 2018

Agile in a kitchen or design?

My two favorite topics just next to the technology are food and design. I love both and I think about both of them most of the time. Therefore, a question appeared in my head: "Does Agile works just for a software development or is it a way of workflow management also in any other areas we will choose?"

Agile in kitchen

Once sitting in a Viennas' restaurant on a meeting brought me to a topic. Can you apply agile framework somewhere between deliciously looking food on a plate and rushing chefs preparing the food? I think it sounds pretty funny, but I do believe you can. In a discussion we had, we grabbed this idea and started going for it.

I have to agree, it was fun to think out of a box in this agile implementation. Still, the conclusion we got to is following. Backlog would be the papers you stick on the wooden beam for the chef to work them off. Of course, the chef relies on given priority of the order. It means person creating chef's backlog knows perfectly the orders and has the ability to organized them accordingly. He might be a Scrum master of your kitchen. As the process is optimized all the food delivery to your customer is once again faster, chefs/waiters/customers less stressed and restaurant is making for sure a bigger profit.

Agile in design

As agile processes can be implemented within any workflow, obviously with a bit of effort. It comes in one's mind to implement it in Design as well as it can be very effective for websites and apps. For instance, you may begin from a user persona that you’ve created, outlining the needs of your target user and using that to branch out and identify the features required. In many organizations, designers span multiple teams (or even products). However, an iterative workflow will see you sitting next to the developer and working in tandem to achieve each iteration as you go.

Understanding the collaborative working style and learning how to estimate will allow you to operate more effectively within a design team. And then, after all, there is Lean UX vs. Agile UX. Many argue that Lean UX is a meaningless term, that doesn’t differ from much older Agile UX and well, it is that way. Exactly, as it is said Lean UX describes methods and their practical application in dynamic environment of a Lean Startup. Agile UX describes update of Agile Software Methodology with UX Design methods. The ultimate goal of Agile UX is to unify developers and designers in the Agile process of product development. Interestingly enough most of the Lean UX teams will actually use Agile UX to coordinate their software development.

So, stay open-minded. Agile is not just for software development? It can be implemented almost anywhere, even in marketing. But let's talk about this topic later.

Our team

August 2, 2018

Does Scrum save your business?

When I met Agile

I used to have startup developing a mobile application. We were two people working hard and at some point successfully, even though we were a big mess. Both of us doing things from design, to coding, to management, to marketing to planning everything needed. Yes, it is a typical startup mess, that we loved.


But as a co-founder I though of future. Mess between two people is still pretty organized mess, but mess in a growing company with many people? That's deadly.

I had no experience with project management, with being entrepreneur or what the hack is Agile whatsoever. I remember almost one year ago I sat at an interview for an IT company. They loved our app and they supposed I know Agile methodology as it's an obvious thing in development. "We work as agile team, we apply Scrum, Kanban, I think, I don't have to explain what it is. I ended up sitting in front of Google and reading tons of articles about what is agile, who is Product Owner and I came across tons of nonsense as well. At that time I got an offer from a different IT company (oh yeah - this one - you got it right)! and I fell in love with Agile framework - Scrum. Now it's my daily bread and I see - it's not about doing agile, but about being agile.

Scrum saving the whole world?

It is said that above 50% of software projects that were implemented are ending up with over crossing a budget, not delivering products on time or ending up with features nobody ever uses. But why? Why we don't wanna count with the changes? Why we use waterfall? All I ever got from kayaking is once you're in a waterfall, you re pretty much f* and have to fall down until the waterfall hits it's bottom as well as it's in waterfall planning. The changes in half of the process in development are so difficult and so expensive to do, that nobody will rather propose them as it's their own showcase of fail or danger of showing weakness in planning. So, could potentially Scrum save old waterfall driven companies or companies which needs different project management?

It's all about the mindset

No, unless... unless you have the right team with the right mindset. Scrum is not a dogma. It's not a pill you take at night and you are healed in the morning. If you want to apply agile, you have to count with huge loss of people who don't have the mindset, who just can't make it. I was lately part of discussion with Martin FiĹĄer, founder of Brand New- a marketing agency - who turn his company to be completely agile. And yes, it was the case when almost 40 % of people left the work, because they just couldn't make it.Now, question yourself - would you risk that as the CEO of a company with thousands of employees? Imagine an international bank turning agile. Where would you suddenly grab 40% of your team to continue the business?

Still, look around the possibilities to transform your business for better tomorrows. Try piece by piece transform or set your team to agile. It will save you lots of money and lots of energy in future. After all, it's all about the mindset transformation, professionals and the team you built from the scratch. So, before going big or going home, if you have the option - try to built from fundamentals agile team as Spotify did, as Elon Musk does as we do. Your life will be easier and still not sweet too much not to make you work hard.


Our team