fbpx
Tag

scrum

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
WRITTEN BY VÁCLAV

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
OUR SCRUM MASTER

August 22, 2018

Agile in a kitchen or design?

My two favourite 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 organised 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
WRITTEN BY VERČA

August 12, 2018

The curse of string distance

When you work for some time on a larger project, you may realise it doesn't perform as well as it did. That is usually expected but sometimes, it just doesn't feel justified.

This was also our case and because the performance of the project was important, we had to get our hands dirty with profilers and debuggers. Of course, we found a few bottlenecks.

The cursed method

Pobody's nerfect, but I don't want to write today about them. I want to write about a cursed method, which was with us right from the start. Which was becoming more and more demanding as we were adding more and more classes.

The curse started from an innocent need.. Let's have short field names in Mongo to have organized layout. Let's have self explanatory bean names in application. Spring very helpfully provides the annotation @Field, which can be used to define different database field name than bean field name. And we used it generously. Just a quick search shows about 200 annotation occurrences.

We found out from profiling, the application is spending unhealthy amount of time in method org.springframework.beans.PropertyMatches.calculateStringDistance. Every field, which had different name than Mongo field, calculated the distance against every other bean field.

To make it worse, the application is processing entities from the database and we had to load about 100.000.000 of them. As you can imagine, the number of calculateStringDistance calls was pretty high. At the end of the day, we implemented a cache in PropertyMatches, but now we have to maintain our custom build of spring-beans. Not something we want to do for the whole life span of project.

The more we looked at the issue, the more we believed the call is not necessary. The distance was calculated for exception message of PropertyReferenceException from Spring Data MongoDB project.  I would argue that a preparation of Exception message should be as light as possible. Still, it can be justified if the message is helpful. This exception is caught in QueryMapper.getPath and method returns null, so we even cannot see the content of message, which drags down the performance. However, the field is still mapped correctly probably (this is where we stopped debugging) using the name from annotation @Field. The existence of @Field  itself suggests the bean name will most likely differ from Mongo field name. The PropertyReferenceException shouldn't be needed in those cases.

Is it something that should be investigated in Spring Data MongoDB? Or is there something we should do on our side to prevent this issue happening? There are not a lot of places in our code where to do things differently though. Our bean fields uses @Field annotation and we don't even have a custom bean converter. This is how we get the entity from database.

MongoTemplate template;
public OurEntity ConvertBsonDocument2OurEntity(Document entityObj) {
}

It's hard to believe we are the only ones facing this issue. If you have some observation or solution, feel free to use our comment section. We also opened the ticket DATAMONGO-1991 in Spring Jira and it would help if more people participate in the discussion. It could be hopefully resolved sooner with more feedback.


Our team
OUR SCRUM MASTER

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.

agile

But as a co-founder I though of future. Mess between two people is still pretty organised 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
WRITTEN BY VERČA