This is why I like to refer to these inquiries as project ideas. They are often the result of some problems the client is experiencing in their day-to-day business. It can be anything from relying too much on paper documents, doing things manually which can be automated, to recognizing an opportunity that a digital platform could seize. Also, most of our clients are not very tech savvy and it’s not unusual that the idea they came up with doesn’t optimally achieve their goals. They are often not familiar with the possibilities of custom digital solutions, which leads to them asking for overly complex solutions to simple problems.

That’s why I think the critical component for making great software solutions (instead of good ones) is the ability to problem-solve—to effectively inspect, analyze, reconstruct, and optimize the client’s idea.

We’re not here just to be code monkeys clicking away predetermined blueprints. The real value of hiring an agency for custom development is the years of accumulated experience they gained working in many different business domains.

The first step we take when we’re approached by a client is to arrange a Discovery workshop. It’s one of the tools we use to actually question the client’s idea or specification. The goal of this workshop is to find out the problems we need to solve, or even better, the value we need to deliver to our clients. We try not to focus on the proposed software solution that much — for that we have later steps such as big picture EventStorming workshops, UX workshops, creating wireframes, etc. Here we try to gain insight into the actual process our client wants to digitalize.

The proper question to ask here is “Why are we developing this application?”, not “What are we developing?”. In the very first step we take, we start learning about the business domain we’re going to be working in, which enables us to better understand the problems the client is facing. Once we know what the real problems are we can start creating a solution together with our clients. Our team had the privilege of working on so many different projects, from a B2B fish market, cycling marathon ticketing system, fashion webshops, protein sequencing AI platform, tourism multi sites, retail webshops, etc. All of these applications required problem-solving and coming up with custom solutions to new problems. All of these applications also came to us as (on the surface) simple project ideas so we had to figure out a way of getting relevant information in a relatively short amount of time from a business domain we’re usually not that familiar with. That’s when we decided to do the Discovery workshop. In this blog, I’ll try to explain our version, especially the project management aspect of it. My dear colleague Petra, who’s our UX analyst, will follow up this blog post with actual tools and practices we implement in these workshops in much more detail.

The first step is to schedule a video call with our client (used to be an actual in-person meeting) where we generally discuss their ideas and problems without a set format. We do this to start a conversation, get familiar with the tasks at hand, and try to get a feel of the problem our client needs to solve. Based on these meeting minutes we prepare a small survey to set up our Discovery Workshop. The questions we use are still quite general, but we’re trying to put our clients in a frame of mind where they’re thinking about the underlying problems and reasons they want the software, not how it should look. For example — What is the main reason you’re looking into developing this solution? How do you think this new system will improve your current situation? What’s the most frustrating thing for you (or your customers) right now? What do you want to achieve in the next 6 months/1 year?

The Discovery Workshop

Before we delve deeper into the actual mechanics of the workshop there’s some setup needed. I’ll leave the details of the actual tools and materials to Petra, and focus on the moderator aspect. Here are some tricks we use to achieve certain goals:

• Encourage activity -> remove all chairs from the room, make sure each member has his marker, set of post-it notes, etc.
• Include all participants -> Make sure that you point out to your client that all levels of stakeholders should be involved in the workshop. We need as much insight as possible
• Visibility -> Have enough space in front of the board for everyone to be able to walk by and see the notes
• Hospitality -> This probably goes without saying but prepare food and drinks as these sessions can get quite lengthy. Also, avoid greasy snacks 🙂

Here’s how we begin our workshop — we first set up a board with the same questions as from the survey we sent, and we group the answers we collected into post-it notes and stick them up on the board for everyone to see. The point is to review all answers one by one, with all present participants. This is especially important if the surveys were filled individually and the participants weren’t aware of each other’s answers. Usually, it’s the first point in the workshop when the Post-it notes will be reached. If the participants don’t have experience with these kinds of workshops, they’ll probably start talking to you directly instead of writing on the board. Remind them to write down their comment and post it on the wall.

Next up we focus on the problem areas. We’re still trying to keep focus on the actual issues each sector (or team) has, rather than talking about the solution. If you manage to gather all roles involved in the business process affected by these issues, each participant will probably have a somewhat different perspective, and maybe even opposing priorities on what needs to be done to improve things. For example, someone working at the cash register might say the current system is too slow and needs too many clicks to perform simple actions, another participant from accounting might say that the reports are not delivered in real-time, etc. Make sure everyone has a say and feels free to comment — each group will have more vocal and dominant members who are used to talking in front of people and easily expressing their opinions. Here you can use brainstorming techniques where you ask everyone to take 5–10 minutes to write down what they think and post it on the wall once they’re done. After a while, you’ll notice some notes are similar or belong to the same domain. Group them if possible.

Now that we have categorized our post-it notes, what we like to do is create user personas on the spot. They can be fictional characters, actual people, or even avatars of the participants. The goal is to focus on the specific perspective of each of these roles in the business process. What motivates them, what causes issues in their everyday workflow, what can be easily improved… Ask the participant who is most familiar with the role at hand to describe their usual day at work — use sticky notes to create a flow and point out the main issues.

If you followed the steps laid out so far you can see that we gathered a lot of information about what actually bothers the client, which issues are the most important to solve, we even figured out different roles that will be included (or affected) by the software solution we’re supposed to build. Here’s the point at which we start talking about the general project idea and what can be done to solve these issues. We tend to use the user story mapping technique where the goal is to create a dynamic frame of interactions and requirements different user roles have. If there’s not enough information yet to be able to come up with user stories for the software, we will do a rough list of different modules and features that the system will need to have. It’s important to point out that the actual scope and specification will be developed in a later set of meetings such as eventstorming, wireframing, user testing, etc. This is a broad overview of the software that needs to be developed based on the project idea, which is now viewed differently after all of the created feedback.

Finally, after we have listed our user stories (or features), it’s time to prioritize and highlight the parts that will bring the most business value to our clients. I suggest combining this step with the user personas to see which features only benefit one role, and which are overlapping and bringing value across the board.

This concludes our version of the Discovery Workshop. There are other activities that we sometimes include, depending on the complexity of the project at hand, such as defining a product vision in combination with an elevator pitch exercise. We always keep these things modular and sometimes even adjust the workshop schedule on the fly depending on the reaction/feedback we’re getting from our client. After the workshop ends, you still need to finish the deliverables which should summarize everything that was learned during the Discovery, list the user personas we created, and show the user stories map. The only rule we keep here is less text and more substance 🙂

To finish this blog post off, here are some general tips:

• Take pictures of each board (especially if you’re changing it for each section)
• If possible record the meeting, or at least have one member write things down
• Remember to take breaks
• Do a short retrospective on the workshop with your team afterwards
• Ask the client for feedback after a couple of days
• Always motivate the group to participate — you don’t want them shouting opinions at the board while you’re writing all of the notes

Originally published at https://locastic.com on Jul 6, 2021.

Product Discovery from the Project Management point of view was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

The issue isn’t the terms themselves, it’s how we introduce them and explain what they really mean. It’s about translating them into something that aligns with the client’s world by drawing parallels that make sense in their context. Believe it or not, colorful post-its and terms like “event storming” can feel more like a playful workshop activity than a serious business process. And when the client’s native language isn’t English, this problem is even worse, especially if you use a bastardized English word without any explanations.

Let’s break down a few common software terms, and how we might better translate them into something more relatable for the client.

Discovery Workshop → Requirements Gathering

“Discovery workshop” sounds exploratory and, in some cases, it is. But to a client, it might not be clear why they need to sit down for a deep dive into what seems like basics. Referring to this session as a “requirements gathering”, grounds it in something more familiar, as a discussion that is essential for any well-run project, software or otherwise. By simply reframing the name, you’re establishing that this is the solid foundation we’ll build upon.

Event Storming → Business Process Mapping

If you’ve ever introduced event storming and watched a client’s eyes glaze over, you know what I’m talking about. The term may evoke images of chaos, they might confuse it with the more popular Brainstorming, or something overly technical. But really, it’s just a fancy way of saying “We’re going to map out your business process”. It’s a clear, visual way to understand how things work within their organization, minus the jargon. Imagine comparing it to sketching out how you’d organize a factory floor or plan a major logistics operation. It becomes relatable, real, and useful.

Wireframes → Blueprints

Wireframes can sound abstract and technical, but calling them blueprints immediately evokes something familiar to most people. Even though it’s not completely the same thing, it’s close enough to explain the reason for creating wireframes instead of diving straight into Hi-Fi designs. They understand blueprints are the skeletal structure that defines how a house is built. In the same way, wireframes define the basic structure of their future product. This connection makes the process feel more tangible.

Moodboard → Design inspirations

You can think of a Moodboard as a panel for collecting design inspirations. It’s not just pretty pictures; it’s a way to explore visual elements that help shape the project’s look and feel. Comparisons can be drawn with interior designers presenting a board of colors, materials, and textures before starting to work on a space.

Environment, Deploy, Launch → Test, Prepare, Go Live

When you talk about environments or deployments, it can quickly sound too technical. Simplify it by breaking it down into phases that the client can easily grasp: Test, Prepare, and Go Live. By shifting to familiar terms, you’re not overwhelming them with a world of development cycles and servers, but instead, you’re explaining how you’ll make sure the product works and is ready to go.

Retrospective → Project Review

The term retrospective can sound unnecessarily complex. What we’re doing is simply a review of a project (or one of its parts) → looking back at what worked, what didn’t, and how to improve next time. The client is familiar with reviews in other contexts, so you’re relating it to something they already know.

Believe it or not, post-its, diagrams, and “event storming” sessions aren’t intuitive to every client. If we present them without proper context, in some professions they might even come across as childish. But with the right language and comparisons, even the most complex processes become something relatable — and ultimately, something they’ll want to be a part of.

There are hundreds of different examples, just think about Scrum or Kanban (burndown charts, story points, WiP, kaizen, etc.). You might as well be speaking in a completely different language.

Remember, at the heart of every project are real people, clients who (mostly) don’t live in the tech world like we do. While we’ll eventually introduce these terms and educate our clients on the nuances of software development, we must start by speaking their language. Drawing parallels, comparing these processes to ones they’re already familiar with, and adjusting our language in those early stages will ensure that clients feel comfortable and confident.

Originally published at https://locastic.com on Nov 21, 2024.

Decoding tech speak for non-tech clients was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

If the velocity of the market is faster than the velocity of your company, you are dead.

Let’s step back for a second and focus on the key aspects of agile. What does being truly agile mean? It means how you respond to changes and how quickly you can change direction and implement feedback into your products, companies, and businesses. Speed is the essence, now more than ever. A few years ago, we lived in a time of lockdowns where every business needed to change and adjust to the new normal. All businesses, no matter how long they had existed, faced the risk of disappearing if they were unable to adjust. For some, this was impossible, but for most, it was a problem of not being agile enough in their processes, getting stuck with procedures, and slow responses to market needs.

199 companies from the S&P 500 mentioned AI in their first-quarter reports for this year — a historical remark for a new technology

The rise of AI is an even bigger challenge. You might not be aware of this or maybe ignoring it, but AI is changing our entire industry at an unprecedented rate. In fact, 199 companies from the S&P 500 mentioned AI in their first-quarter reports for this year — a historic milestone for a new technology.

AI is changing every aspect of our lives, making many things possible and faster. If you are not adjusting and using it daily, you risk falling behind. Just a few years ago, you needed a team and several months to build a simple MVP to test your idea. Today, an average person with an AI assistant can create a simple MVP and a marketing plan in a matter of days. While the quality may not be the same, the value gained from the speed and ability to test ideas in the market far outpaces the perfect MVPs that tech teams build in months instead of weeks.

Even Darwin, a hundred years ago, explained agile in a simple way: you need to adapt to survive. Darwin’s theory underscores the importance of adaptability, iterative improvement, responsiveness, collaboration, and surviving competitive pressures — all of which are central to agile development.

You don’t need expensive consultants in their expensive suits; you need common sense!

It’s funny how Agile has ended up being an expensive game of consultants. Think about it: you have people going around telling you how to build software. Most of them lack real-world experience and merely evangelize methods and books they’ve read while earning substantial money for it. This is why we end up with retrospectives where serious engineering teams are required to play games like “Three Little Pigs,” which measure energy levels, or my favorite — the “Kinder Surprise Retro” game, where you need to explain how a Kinder Surprise toy represents you in the current sprint. WTF?

”I’m sick of it. I can’t wait for the day when everyone realises how much of a fad-diet, religious-cult-inspired, money-making exercise it is for a group of consultants. I can’t wait for people to wake up to the fact that the only good parts of Agile are just basic common sense and don’t need a ‘manifesto’ or evangelists to support them.”

-the rant of Luke Halliwell some fifteen years ago

I fully agree with Luke and feel his pain. However, I do slightly disagree on one point: I think it is good that the Agile Manifesto was written. It is valuable to have it documented and to reflect on its principles. But the more you think about it, you realize that everything in it is common sense — focus on adding value for your customers, be able to respond to changes and prioritize working software over useless procedures. But the rest of Luke’s rant? I sign it 100%.

Have you noticed the rise of AI consultants training people to write ChatGPT prompts? Do you know if you can ask ChatGPT to write them? I’m just asking.

Top-down vs. bottom-up! Stop being a heroic command giver, and start being a humble gardener.

One of the reasons we widely accept consulting services is because the management of mid and large companies can delegate responsibilities to them. The story typically goes like this: management realizes they need to change something, for example, becoming more agile (whatever that means to them). The next step is hiring consulting teams, paying them a lot of money, and then delegating everything top-down, ordering people to be agile from this point on. But you don’t build a house from the top down, right? The biggest problem here is that management delegates part of the responsibility while continuing to act as before, with no changes in their processes or mindset. You cannot implement agile as an order; you need to embed it as a core value of your company.

If you are an agency forcing your delivery/development teams to be agile but still selling your projects in non-agile ways, how can you call your company agile? How can you expect this to even work? Management needs to understand that agile is not a set of procedures and tools; it is a philosophy that must be embedded in the backbone of the company and implemented from the bottom up. If development teams are working in an agile way, the sales teams should adjust and sell in that way. Management needs to adjust and lead the company in the same way, sharing the same core values and obsession with adding value to the customers and company as the development teams. They should be on the same page and pursue the same goals. Listen to your people and use common sense more than expensive consultants with one-size-fits-all patterns, as there is no silver bullet solution.

Just a quick disclaimer: I don’t think you should avoid hiring consultants or providing training for your team. Just be mindful of who you are hiring and what they are selling to your team. Ensure they have some proper experience and are not just some crazy evangelists. Additionally, if you are part of top management, be involved and start implementing the same principles yourself.

Source: What is agile?

There is no plan; the plan is everything! The customer is king!

In the times we are living in, there is no concrete plan for the next three years. There is only the market and your customer. When I say there is no plan, I mean there is no fixed plan for what the next priority is, as priorities can change daily or weekly. Of course, you will have goals and plans for what you want to achieve in the next few months, years, and decades, but these must be adaptable. You need constant feedback from your data and your customers.

In today’s competitive markets, customers have many choices and alternatives for any product. They expect instant, frictionless, and intimate responsiveness at scale. If you are not delivering this, someone else will, and your customers will go to the competition. It is literally a listen, adjust, deliver, or die situation. This is common sense; you also act this way with products you use, so don’t be surprised by your customers’ expectations.

Remember the top-down problem with management? Usually, feedback from customers comes from the bottom up. If management does not accept this feedback and treats “the customer is king” as just a phrase, you can see why such an organization cannot be called agile.

When I said there is no plan, I meant the plan is everything. This is your backlog. At any point in time, your backlog needs to be updated with the highest priorities. Every single thing, including priority, can be changed at any point with a focus on adding value for the customers. If you achieve this, you have taken a great step toward calling yourself an agile organization.

Your product owner is a superhero!

The book “The age of agile” by Steve Denning illustrates how smart companies are transforming the way work gets done in the modern world using agile. If we sum up the book, we see that agile operates under three laws:

1. The Law of the Small Team

Big and difficult problems should be disaggregated into small batches and performed by small cross-functional teams working iteratively in short cycles and in a state of flow, with fast feedback from customers and end users.

The Law of the Small Team from “The Age of Agile” emphasizes the effectiveness of small, cross-functional teams that work in short, iterative cycles. These teams have the autonomy to make decisions and quickly adapt to changes, promoting innovation and faster delivery of value to customers. Small teams foster closer collaboration, better communication, and increased accountability, leading to higher productivity and more effective problem-solving.

2. The Law of the Customer

An obsession with delivering value to customers as the be-all and end-all of the organization.“

The Law of the Customer highlights the importance of prioritizing customer needs and feedback in the development process. Organizations should focus on delivering continuous value to customers through iterative improvements and close engagement. By actively listening to customers and rapidly responding to their evolving needs, businesses can build stronger relationships, increase customer satisfaction, and drive long-term success. This customer-centric approach ensures that the products and services offered are aligned with what customers truly want and need.

3. The Law of the Network

A continuing effort to obliterate bureaucracy and top-down hierarchy so that the firm operates as an interacting network of teams, all focused on working together to deliver increasing value to customers.“

The Law of the Network stresses the importance of fostering a network of empowered teams within an organization. Instead of rigid hierarchies, companies should create flexible, decentralized networks that encourage collaboration and information sharing across all levels. This networked structure enables faster decision-making, greater innovation, and a more adaptive and resilient organization. By leveraging the collective intelligence and capabilities of the entire network, companies can respond more effectively to changes in the market and continuously improve their performance.

Source: How to build a strategy in an agile environment

As you can see, all of these three laws from “The Age of Agile” focus on a simpler organization with bigger output/value for the customers. Again, common sense. But in practice, not everyone is aware of this. This should be accepted by all people involved in the project, including investors and stakeholders. For example, if you have an investor who has put money into your project, they are expecting some returns in the future (don’t tell anyone, but this is how the world works). I will tell you one more secret: even if you are a consulting/development agency, your client’s customers are kings — you need to listen to them as they are paying money to your client/stakeholder, which they are using to pay you. Again, common sense, but usually this is not how it works and not how stakeholders understand it.

To be obsessed with your customers, you need a superhero on your team. While superheroes may not be real, we have heroes in the form of Product Owners. When developing a product, the Product Owner needs to be fully in charge. What does this mean? It means that the Product Owner must have full control over the product, backlog, plans, and more. They need to be in touch with customers and, more importantly, have the courage and ability to say no to stakeholders, CEOs, bosses, etc. I know this is almost impossible, but this is what we need for great products: great people with more freedom and responsibility. Most importantly, the Product Owner is responsible for the product. They are the connection between stakeholders, the development team, the marketing team, the sales team, and the customer, and they need to perform at the highest level.

A Product Owner is not a Project Manager.

Often, these roles are conflated or assigned to the same person. This is completely wrong. I read a good comparison on LinkedIn, so I will use it here.

A Project Manager is like a band that comes to play for 3 hours and will get paid for it. The Project Manager prepares the list of songs that fit the budget and 3-hour session. The Project Manager ensures that everything goes well and stops the band after 3 hours.

A Product Owner, on the other hand, starts watching the crowd as soon as the band begins to play. The Product Owner’s only focus is to keep the crowd dancing as long as possible and to ensure they have fun. If a set of songs or a genre is not working, the Product Owner adjusts and changes, implementing feedback.

You see the difference here: the Project Manager is in an execution role, while the Product Owner needs to know their “crowd.” They need to find what fits their “crowd” and make them “happy and cheerful.” It is not an exceptional role; it is a key role. To do this, the Product Owner must take a significant role in understanding the business and all roles within it. If you want to know more, read Ana’s blog post.

You can be agile (even) if you are using a waterfall.

First, let’s clarify something — there is no “right way” or “best way” to build software. There are guidelines that can help increase your chances of success, but the reality is that around 70% of projects fail. The only way to build good software is by adapting theory to fit the needs of the customer, budget, codebase, team, tools, and organization.

Even within the same organization, different teams can perform differently using the same procedures and workflows. In the end, do you really think your customers (kings) care what methodology you are using to deliver value to them? Do they care about the technology stack you are using? No, and no. They only care about their need at the moment. If they want to send a picture via chat, they want to do it quickly, and now — that is the only thing they care about.

The only way to build good software is by adopting theory to fit the need of the customer, budget, codebase, team, tools and organisation.

Usually, I hear, “We need Scrum to be agile.” This is nonsense on so many levels. First, if you implement Scrum without an agile mindset, you will get stuck in countless meetings and ceremonies, and your teams will soon be frustrated, complaining that they don’t have time to work and are doing too many meetings (sounds familiar?). Scrum is the most popular framework, and when you start learning about agile methodologies, you will often end up trying Scrum. You will hire trainers, and consultants, read books, and try to do everything by the book and the rules of Scrum, but it will probably not work. The problem is not that Scrum isn’t working; the problem is that you didn’t implement agile in your core values and focused too much on the Scrum procedures.

Remember, Scrum is a framework. And what do we do with frameworks? We adjust them to our needs. Yes, we make compromises to fit the team and project we have, aiming to build the best possible product. Hopefully, you will not end up playing “funny” games with adults who just need to provide feedback on what was good, what was bad, and how to improve. In the end, you can invent your own methodology and call it “deliverscumic.” If it allows you to deliver value, quickly respond to changes, and keep your customers happy, then from my point of view, you are doing agile well.

Some projects need to be waterfall. Let’s move from IT for a second and consider another example: building a house. If you are building a house, you know that this is one of the most agile projects you will ever work on, but it must follow a waterfall approach. First, you need to find the land, then buy it, do the legal work, and get all the necessary permissions. Next, you create the entire project and blueprints (wireframes 😊). Once this is complete, you can start building, then choose your furniture and buy everything. It is clearly a waterfall process, but each of these phases requires significant agility.

This can be a multi-year project where changes in market prices can affect the entire investment, necessitating quick adjustments. When construction begins, unexpected problems often arise, requiring immediate decisions on how to fix them. Don’t tell me you need a good architect who can predict everything — there is no single architect in the world, whether in building or in software, who can predict and solve all problems upfront. You see where I am going: this is a clear waterfall project, but each phase within it is chaotic and requires agility.

Deliver MVP to the market asap!

Back to IT projects and products: if you are starting a new project (like building a new house) and don’t have any data or feedback from customers, it makes sense to implement a waterfall approach at the beginning. Initially, you need to make some assumptions about the market, conduct discovery workshops, and define the product idea. This phase is also an opportunity to conduct customer interviews, gather feedback, and begin incorporating agility. The result of the discovery workshop might be that your product is not needed in the market, and that’s perfectly okay — you’ve saved a lot of money on development. On the other hand, if there is a market fit, the result should be a clear roadmap to the MVP.

An MVP should not be a sloppy project that barely works and is rushed into production to meet deadlines. Developing an MVP forces teams to focus on the core value proposition of the product. By identifying and delivering the most critical features first, teams ensure that the product addresses the primary problem it is intended to solve. This focus can lead to a more coherent and user-centric product.

By getting a working product into the hands of users quickly, teams can gather valuable feedback and learn about user needs and preferences. This feedback loop helps in making informed decisions and prioritizing future development — allowing teams to get feedback, adapt, and add value for the customers.

Agile development emphasizes adaptability and responsiveness to change. An MVP aligns with this principle by allowing teams to iterate and improve the product based on real-world usage and feedback. This iterative approach ensures that the product evolves in a direction that is aligned with user needs and market conditions.

An MVP is important in agile development because it enables rapid learning, reduces risk, ensures cost efficiency, accelerates time to market, promotes flexibility, engages stakeholders, and focuses on delivering core value. These benefits align with the agile principles of iterative development, responsiveness to change, and delivering value to customers. Once you release your MVP to production and start gathering feedback and data, that is likely the exact point where a waterfall approach no longer makes sense.

There is no one-size-fits-all approach for companies

As there is no single company, project, or situation that is the same, even if two different teams work on the same project with the same methodology, the outcome can be different. Based on our experiences, we know that some things work better and some things work less effectively in certain situations.

For example, if you have a fixed budget, fixed deadline, and fixed scope, it makes no sense to try to do agile. This is a project (if such a project even exists) where everything should be written in stone, and no changes should be made. In such cases, agile is not the appropriate approach.

Based on our experiences, different project methodologies should be applied depending on the situation. You will not use Scrum for a simple MVP. Typically, if you are building a new project, you might start with a waterfall approach but transition to Scrum or something more agile as soon as things become complicated and plans start changing more frequently. Additionally, if you are taking over a project that is in total chaos, Kanban will likely give you better and quicker results compared to Scrum.

The same applies to your business; there is no simple solution or silver bullet that will transform your business into an agile company. You need to work on this every day, with a focus on adding value by listening to your customers and their feedback. It is crucial to involve your project team in the acquisition phase as early as possible (law of the network). This will allow you to detect low-effort features with great value for the customers, providing some easy wins for you.

Be agile with agile, and don’t be a slave to any framework or methodology!

Breaking the rules and experimenting with new approaches is also an important part of being agile. Don’t be constrained by the book rules, as they usually will not work exactly as written but can provide some good ideas. Start with new ideas, do retrospectives often, and try to fix what is not working for you. In a few cycles, you will adjust the framework and process to fit your needs and create something that works for you. This is crucial: you need to figure out what works for you and your project, enabling you to adjust to requirements and changes easily.

Be agile with agile, and don’t be a slave to any framework or methodology!

Originally published at https://locastic.com on Oct 23, 2024.

Are you failing at being agile? was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR:

• Beware of the Dev#Popper Scam Targeting Developers: An advanced scam is on the rise, deceiving developers with fake job offers that seem too good to be true, especially in the blockchain and web3 communities.
• The Hook, Line, and Sinker Strategy: Scammers lure developers with lucrative opportunities (the hook), engage them in tasks that require downloading code (the line), and finally compromise their systems with malware hidden in the codebase (the sinker).
• Real-Life Examples : From fake projects on platforms like Upwork to sophisticated setups involving referrals and staged company profiles, the scam manifests in various convincing forms.
• How to protect yourself: The malicious code is often deeply obfuscated and embedded in familiar files. Learn how to identify suspicious patterns and signatures to safeguard your assets and devices.
• Why Crypto Developers Are Prime Targets: Due to their access to digital wallets and private keys, crypto developers are especially vulnerable. Scammers exploit the fast-paced nature of the crypto industry and developers’ habits of downloading code.
• Stay Vigilant and Informed: Implement rigorous verification processes, use sandbox environments, and maintain a healthy skepticism towards unsolicited offers. Community collaboration and sharing experiences are key to combating this threat.

We all know scams are a daily risk online. Scammers are usually after our money, but gaining access to personal information is just as valuable for them. There are many types of scams out there, usually aiming for less technical persons and using social engineering tactics to manipulate people into taking actions — like investing money in scams, downloading harmful software that gives scammers access to personal data, and tracking your every move until they get a perfect attack opportunity.

In late 2023, I came across a more advanced scam targeting developers who are actively seeking new job opportunities, known as the dev#popper scam. By 2024, especially from Q2 onward, I saw a significant rise in this type of scam. It’s now clear this trend primarily focuses on blockchain and web3 developers, but it’s also affecting others in different tech communities.

The dev#popper scam uses hook, line, and sinker patterns

Scammers lure developers with lucrative opportunities (the hook), engage them in tasks that require downloading code (the line), and finally compromise their systems with malware hidden in the codebase (the sinker).

– Image Source: Palo Alto Networks Unit 42

Scammers lure developers with lucrative opportunities (the hook), engage them in tasks that require downloading code (the line), and finally compromise their systems with malware hidden in the codebase (the sinker).

The hook

Imagine you’re a blockchain developer, or any kind of software developer, looking for new job opportunities (or you just get a message from a recruiter or even startup CEO). They present their project and opportunity to you, everything at first looks amazing: there’s a team, a challenging project, a LinkedIn page, an X account with many followers, and even a Discord channel. Every single team member has a profile; even documentation exists, and they present you with a vicious offer — sometimes even too good to be true. It’s the opportunity you’ve been waiting for. This is the hook.

Sometimes the bait is quite basic, and you’ll notice the scam very quickly. But I’ve seen baits where they’ve invested a lot of energy building team bios, history, websites, documentation, etc. As described, at first everything seems legit. The good thing is, once you see and notice the bait, it becomes quite easy (if you’re careful) to recognize the pattern.

Some dev#popper hook patterns and strategies that we see often:

• Using Telegram groups: Scammers are posting lucrative offers in Telegram groups where the web3 community is active (for example, events/conferences groups). Once you contact them via DM, they try to move to the Line phase.
• Upwork jobs scam: Upwork is full of scammers; basically, if there are new clients posting blockchain/web3 jobs with no reviews, it’s 90% likely a scam. If they contact you with a repository and give you some test — skip it.
• Inquiries to agencies via hire us forms — this is happening more often, seems they are looking for new victims, even if the agency is not doing web3 development.
• Building a network and using referrals: One of the most advanced was when we got a referral from our partners, and it ended up being a scam. To be honest, at first, everything looked legit, but it was too good to be true. Once we got the codebase, we found malware and asked them to do KYC, but they never (ever) did it.

Since they are playing in large numbers to find their victims, as with every scam, hook patterns are quite similar. In this case, they will post a lucrative job offer. They will ask you to do some tests to do simple wallet integration, or to check some bugs — some will ask this as a test assignment, and others will promise payments for it — the common thing is that the code base will already exist, and malware code is inside. Most of them will promise long-term collaboration if you do step one successfully.

The Line

Once you are hooked, the second phase begins — the line. Once the developer is interested, the “line” represents the continued interaction that pulls them deeper into the scam. The scammer may engage in convincing communication, provide contracts, or request specific tasks like building a prototype or sharing sensitive data. The developer, at this stage, feels invested in the opportunity, which keeps them connected to the scam.

Usually, the line will go in two directions. One is that their previous developer left them for any reason, and they need someone to save the project. The second one is, before the interview, you need to review some code and add some basic features. Both directions have the same goal: you have to download the codebase (repository on GitHub or Bitbucket) and run it on your machine. You see where this is going. This is the key phase; as described below, this code contains malware that adds a trojan horse to your computer.

The play here is simple: the task is urgent, you just need to do a quick bug fix or add a simple task, and they need it ASAP as most urgent. They are leveraging the hook and applying pressure while you are still hot and interested, hoping you’ll make a mistake. Usually, scammers will not jump on a call with you until you do the technical assignment; in reality, they are playing large numbers, some of them are using bots, and they will never go on the call with you.

Did you ever get a Nigerian prince on call?

I didn’t think so…

The sinker

The “sinker” is the final phase where the developer is fully “hooked” and suffers the consequences. Once you install the codebase and run it — you are sunk, as you’ve installed a hidden part of the code that is a sophisticated remote access trojan (RAT), and in this case, there is no antivirus or anything that can help you. Also, this works on all machines and platforms since it leverages npm, and if you have installed the code, you have npm.

Usually, this trojan horse goes through every single file on your computer, searching primarily for wallets, private keys, and seed phrases, but it’s also searching for all other information that could be useful for further attacks — like email logins. While you are working and analyzing the code, the malware is silently infiltrating your system. It’s logging your keystrokes, accessing your files, and worst of all — it’s specifically searching for the crown jewels of any crypto developer’s machine: seeds and private keys. Usually, the result is empty wallets.

Dev#popper scam real-life examples

Usually, you will get reports that have frontend and backend applications. Mostly, it is a Node.js and React combination, and everything looks familiar, with regular code inside.

One of the simplest ways is when they send you a ZIP file with NPM packages; usually, the malware code is hidden in some preinstall NPM packages. Of course, the second way is that they make a typo in the package.json file, and you end up downloading malware instead of a regular library.

In more advanced ways, the code is usually heavily obfuscated and hidden. Let’s dig deeper into the first example.

Coinpoker fork with CHIP token

So, we got a referral from one of our partners that the profile @marioveteran on Telegram is looking for blockchain developers and he is building an online casino. He is still active, so be aware. The project description, in short, was that they needed someone to do web3 wallet integrations, payment gateways, multiple poker rooms, admin pages, etc. — in general, everything that CoinPoker has, and the UI would be a fork of CoinPoker. Of course, they already bought licenses, and the previous developer was unable to deliver them.

We started talking directly with @marioveteran and we got an invitation to the repository, and everything seemed okay. It is a React and Node application; by the names of variables and functions, it has some connection with poker and gambling. Since we were aware of the scam, we decided to dig deeper as we didn’t see anything in the package.json file, but the entire feeling was — this is a scam play, this is dev#popper play.

We searched for some known scripts, and voilà — tailwind.config.js. But hidden in a very smart way; try testing it with developers — I am sure 8 out of 10 will not see the scroll trick on the first try.

And when you scroll right, there is a hidden part of heavily obfuscated code.

I will not share the code here because I don’t want to allow other potential scammers to use the code for scamming people. But let’s use ChatGPT to analyze the code.

Here is the ChatGPT answer:

The code you’ve provided appears to be malicious in nature. Here’s a breakdown of key indicators:

1. Obfuscation and Encoding:

• The script uses Base64 encoding (e.g., “base64”) and UTF-8 encoding to hide its real functionality. For instance, n(c) calls Base64-decoded strings, which then reference modules like fs (file system), os (operating system), and others.
• The strings are deliberately obfuscated, and function names are encoded and concatenated to make it difficult to understand the real behavior of the code at a glance.

2. System and File Access:

• The script accesses several critical system functions, like retrieving the hostname (hostname()), home directory (homedir()), platform (platform()), and temporary directory (tmpdir()).
• It interacts with files using the file system (fs) module. It seems to check for the existence of specific files and directories, possibly for reconnaissance and potentially writes or modifies system files.

3. External Requests:

• The code imports a request module (rq=require(n(“YcmVx”+”dWVzdA”))) which is likely being used to make HTTP requests. This could mean that the script is communicating with a remote server, which is a common behavior of malware for the exfiltration of data or receiving further instructions.

4. Buffer and Process Execution:

• The script uses Buffer and the execution of system commands through a child process (e.g., ex=require(n(“aY2hpbGRf”+”cHJvY2Vzcw”))[n(“cZXhlYw”)]). This could be used to run commands on the system, possibly to download additional malicious payloads or to perform other harmful actions.
• There are indications that the script might be unpacking or downloading additional malware, based on how it handles different directories and file structures.

5. Behavior and Automation:

• There is a timer (setTimeout) and a recurring interval (setInterval) indicating that the script runs continuously in the background, which is typical for malware trying to persist on a system and perform malicious actions over time.

6. Network Activity:

• The code seems to build URLs dynamically and might be trying to communicate with remote servers to send system information (hid, hostname, etc.), which can be used for tracking or control by a remote attacker.

The code shows strong signs of being malware, given its obfuscation, system, and file access, external communication, and potential for executing harmful commands. You should avoid running this code and take immediate action to secure your system if it’s been executed, such as running antivirus scans and disconnecting from the network.

While we were analyzing the code, we asked Super Mario to do KYC. You guess the result.

Upwork scams and dev#popper examples — meet YAMTOKEN

When we decided to write this article and do the research, we noticed that many people were complaining about too many scams on the Upwork platform (check Reddit also). So we decided to do research by ourselves. In just a few days, we sent offers to some crypto projects, and all we got were scams. There are a lot of blockchain job posts, and I assume if they don’t have a good track history (more than a few projects) or if they have zero projects, they are 99% scams. The flow will go in a way — you apply for the job, and you get a message with a repo and a test assignment. Usually, the code will be the same as the previous one, but we also found one more advanced.

Note: CryptonStudio exists, and someone is trying to impersonate them — quick research on LinkedIn and the web didn’t give any results about person Mohamed Waleed in CryptonStudio

Once we got the repository, we started our usual check and we didn’t find anything. Again, the play was as usual — dev#popper for sure.

So we started digging deeper, checking even forks, and developers — but of course, the repo is new, and the developer who made it is new — more signs that is dev#popper play. Our regular checks for suspicious code returned nothing. So, we went deeper and checked if there was some script that is loaded via JavaScript code. Of course, it is. Once we found the getPassport.js file, we noticed some external script was loaded. But first, let’s examine the getPassport.js file itself.

Again, quick ChatGPT analyze:

Upon analyzing the code, we noticed that it imports the ‘Axios’ library and defines a function called getPassport. This function makes a GET request to a specific URL: http://w3capi.marketing/api/v2/node/8b7c0c4970b1eb5878036a62ef22eaed. If the request is successful, it retrieves res.data. However, if the request fails, it catches the error and executes eval(err.response.data).

Using eval on data received from an error response is highly dangerous and is a common technique used in malicious code. This approach allows the execution of arbitrary code provided by the remote server in the error response, which can compromise the security of the system running this code.

Therefore, this code is malicious as it can execute arbitrary code from an external source, potentially allowing an attacker to run any code on your machine.

And finally, let’s check the file that is loaded from the remote server.

The code provided seems to perform several tasks, but it contains multiple issues that need to be addressed for better understanding and security:

• System Information Gathering: The code collects information about the operating system, such as the type, platform, release version, hostname, and user information.
• File System Scanning: The script scans directories on the user’s computer, specifically targeting files with extensions such as .txt, .js, .json, .py, .env, and others that may contain sensitive data.
• Sensitive Data Detection: It reads the contents of these files and uses regular expressions to look for patterns that match:
• Bitcoin Private Keys: It searches for strings that match the format of Bitcoin private keys.
• Ethereum Private Keys: It looks for 64-character hexadecimal strings that could represent Ethereum private keys.
• Seed Phrases: It scans for sequences of 12 to 24 words, which are commonly used as seed phrases for cryptocurrency wallets.
• System Information Gathering: The code collects information about the operating system, including the type, platform, release version, hostname, and user details, and sends this information to the remote server.
• Execution of System Commands: It may execute system commands to change file permissions or install additional packages, potentially modifying the system without consent.
• Persistence Mechanisms: It sets intervals to repeatedly execute certain functions, suggesting an attempt to maintain persistence on the system.

Important Considerations:

• Malicious Intent: The script exhibits behavior characteristic of malware designed to steal sensitive information, particularly cryptocurrency-related data.
• Security Risks: Running this code can compromise your system’s security, leading to unauthorized access to your private keys and potential loss of funds.
• Legal and Ethical Implications: Unauthorized access to and transmission of personal data is illegal in many jurisdictions and unethical.

Recommendations:

• Do Not Run the Code: Avoid executing this script on any computer or device.
• Secure Your System:

1. Disconnect from the Internet: Immediately isolate the affected system to prevent further data transmission.
2. Change Passwords: Update passwords for all accounts that may have been compromised.
3. Scan for Malware: Use reputable antivirus or anti-malware software to scan and clean your system.
4. Check Cryptocurrency Wallets: If you use cryptocurrency wallets on the system, verify that your funds are secure.

• Consult a Professional: Consider seeking assistance from a cybersecurity professional to ensure your system is thoroughly cleaned and secured.

Preventive Measures:

• Be Cautious with Untrusted Code: Only run scripts and programs from sources you trust.
• Keep Software Updated: Regularly update your operating system and security software to protect against known vulnerabilities.
• Backup Important Data: Maintain regular backups of your important files in secure locations.

Conclusion:

The code is malicious and poses a significant threat to your personal data and security. It is designed to search for and exfiltrate private keys and seed phrases associated with cryptocurrency wallets. Immediate action is recommended to safeguard your assets and information.

But even without the AI code review, if you check the file it is clear it is malicious. They even left a comment where is regex for searching for Seed phases and private keys.

Don’t get me wrong, I think Upwork is an amazing platform, but for sure they will need to invest more time fighting the scams, especially in web3 and blockchain jobs. Here is one more example to be aware of:

How to defend against the dev#popper scam?

Assume everything is a scam; first, verify, then trust. Start with simple googling and research, and you will avoid 90% of scams — remember they are doing repetitive things on a large scale, so there is a good chance someone already wrote about it. Always independently verify the identity of the company or individual; if you suspect a scam, ask them to do KYC — they will never do it. But even if they do, still be careful and be skeptical of urgency.

Sandbox everything and use VMs for new projects if you don’t have separate machines. Don’t ever run something that you are not 100% sure about in your environment where you are holding wallets and crypto assets. Virtual machines or dedicated testing rigs that can be wiped clean are essential tools.

Do a quick search for signatures in the code; it is quite likely that you will find some of the 4 signatures below (‘cGxhdGZvcm0’, ‘dGVhbTE1’, ‘FhwPVBErFkoaFwNLBg’, ‘ORsFWRlUNUwUAAM’). If nothing is found, check for Axios and eval functions and what external scripts they are loading.

Check more in detail Telegram and Discord groups, as well as X and LinkedIn pages — it’s quite easy to see when something is staged and not real (fake accounts as followers, etc.). With GitHub repos, if there is only one commit, one contributor, and both things are new — it’s a scam. Just skip it.

Use common sense; if something is too good to be true and you cannot verify it 120% — it’s a scam. Usually, scammers are using bots, or they are not that good in English and there are many mistakes in their storyline. Just raise your level of attention to the details and ignore the pressure they are putting on you. They will not invest much time in you if you are a tough player; remember, in most cases, they are playing on large numbers. But if you are a bigger fish and you expose yourself a lot, be double cautious.

Personal security is a big and important thing, even if you are not in crypto. Keep yourself regularly informed about security threats and scams, and share anything new you notice. We need to take care of each other. Also, keep low and don’t show off how much money you have in your wallets (you are not walking around with a screen showing your bank account); keep your wallets private and never keep private keys on internet-connected devices. Stay vigilant, stay secure.

Why are crypto developers usually targets for scammers?

Crypto developers are primarily targeted by the dev#popper scam mostly because of the assets they usually own. A single private key could grant access to millions of attackers. Blockchain developers usually have direct access to digital wallets, private keys, and other sensitive financial assets on the computers and devices where they do development. Once assets are stolen, it is difficult to trace and impossible to recover.

Crypto developers regularly work with code repositories, libraries, and open-source projects; they’re used to downloading and running code from various sources. This allows scammers to embed malware or trojans in codebases that appear legitimate. Once developers get hooked and install and run the code, it is already too late.

The blockchain and crypto industry is fast-paced and there are numerous new startups and projects, some of which may not have an extensive track record. This environment makes it easier for scammers to pose as legit companies or recruiters, offering amazing job opportunities that seem too good to pass up. They leverage social engineering tactics, creating a sense of urgency or exclusivity (or easy money) to pressure developers into acting quickly without thorough verification.

The combination of all the reasons above is why blockchain developers are easy and valued targets.

The dev#popper scam is a highly sophisticated and planned campaign

The dev#popper is a highly sophisticated and long-term planned campaign aiming primarily at crypto developers, but also targeting other communities and non-crypto developers. It is hard to estimate how much assets and money were stolen in this campaign, but we can assume we are talking about millions of dollars.

Attackers can be patient, and they understand the psychology of job seeking and the weaknesses of developers; excitement of a new role, pressure to prove yourself, and the lure of high rewards are all key factors that affect our minds when this happens. It can be compared with the tailor scam in Thailand; it’s the same play, just different topics and players — so there are years of experience behind it. Just in this case, it is more sophisticated and adjusted to developers.

Moving forward, scammers are getting better and better at social engineering. With the growth of remote work, companies and individuals are more exposed to scams than ever before. Staying safe is a never-ending game, and we need to implement rigorous verification and enhanced security tools as a regular part of our work. Staying informed and community collaboration to share experiences and report suspicious activities is crucial.

Stay vigilant, stay secure, and keep building.

It is clear that we need a better way to verify individuals and companies in the future, and maybe Blockchain technology will make this possible. Until then, stay vigilant, stay secure, and keep building.

Originally published at https://locastic.com on Oct 8, 2024.

The “DEV#POPPER” scam targeting crypto and Blockchain developers was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Annotation class

First of all, we will create ElasticSearch annotation. It will be later used for defining the populating groups in resources:

Resource with ElasticSearch groups

Now we can use it on the resource we would like to populate. It’s possible to add groups to relations too, but make sure you add the group to the relation ID.

Creating ElasticSearch index and populating data

The next step is to create a command that will create indexes for all resources without mapping. Dynamic field mapping will take care of that when the data starts to populate.

Event Subscriber for keeping everything up to date

Since our index needs to be up to date, we should update it on each change in the database. Depending on your application, you can do it either as an Event Subscriber or a Data Persister. In this case, we are using Event Subscriber:

In each action we are fetching serialization groups, so they can be sent to the normalizer. Finally, we call ElasticService which will send a request to ElasticSearch.

ElasticSearch Service

The following service is in charge of creating and sending requests to ElasticSearch. Symfony normalizer will generate a body for the request using our groups:

Denormalization of integer and float

You might have a problem with integer and float denormalizing to string when pulling data. But this can be easily fixed by decorating ApiPlatform\Core\Serializer\ItemNormalizer and disabling type enforcement in the denormalize method:

Conclusion

Now that we prepared all needed, we are able to add a new resource to ElasticSearch by just defining groups in annotation and assigning them to fields we want to have in the index.

Originally published at https://locastic.com on Oct 30, 2020.

Populating ElasticSearch using serialization groups in ApiPlatform was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

So let’s get started with creating an export for our Order entity:

The first step is to create a DTO with fields we would like to have in the CSV file. After that, we added the serialization group order-export which will be our normalization-context group for exporting endpoint.

The next step is to create a DataTransformer which will transform the Order entity into a DTO object:

Finally, we are ready to create the export route in the Order entity:

There are a few important things in this configuration:

• “formats”={“csv”={“text/csv”}} -> Here we set the route format to CSV
• “pagination_enabled”=false -> In export, we want to show all orders, not just the ones on the first page. Therefore we disabled pagination for this route.
• “output”=OrderExport::class -> This line is telling ApiPlatform to use the OrderExport DTO we prepared, instead of the Order entity.
• “normalization_context”={“groups”={“order-export”}} -> Here we set the serialization group we used in DTO

And that’s it! Now we can send a request to /orders/export and we’ll get the CSV. Since we didn’t implement custom export, we can still leverage built-in API Platform features. Therefore we can use all available filters just like we do on regular endpoints for Order entity.

In fact, this is not just a way to make the CSV export — you can use it for any other format too.

Originally published at https://locastic.com on Mar 4, 2020.

Easy CSV export in API Platform was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Luckily for you, there’s a bundle that could probably help you. I named it LocasticApiTranslationBundle and it’s inspired by Sylius translation which uses the approach of personal translations.

Sylius is an Open Source eCommerce Framework based on Symfony full stack. The technology is constructed from fully decoupled components (bundles in Symfony glossary), which means that every feature (products catalog, shipping engine, promotions system…) can be used in any other application.

symfony.com

What’s the idea?

First of all, each entity has a related translation entity that holds all translatable fields. Using serialization groups you can either return the object translated to a rather single language or use another way — return an embedded collection with all available translations.

Let’s get down to coding

1. Create translatable and translation classes

Let’s assume that we would like to have an Event entity with translatable fields, then we need to make Event and EventTranslation classes. As a result, let’s take a look at the Event class:

Event needs to extend the AbstractTranslatable class and implement a method for creating a new EventTranslation object. AbstractTranslatable class provides getTranslation() method which gives us access to our translation class.

Because of this, we are able to make virtual fields for title and description and set their translated values. $translations variable is overwritten just to add group for writing Event object.

Translation class is somewhat simpler, because to only important thing is to extend AbstractTranslation and add corresponding serialization groups:

• When it comes to doctrine relation between Event and EventTranslation make sure that you set fetch to “EXTRA_LAZY” and index-by to “locale”.

2. Create API resource

Therefore, the next step is to create a resource for Event and EventTranslation classes:

You should note two things here:

• PUT and POST operations have a translations normalization group because we want to return a full collection of translations for response.
• We added translation.groups filter, so that client is able to request full translation responses for any operation if necessary.

All ready!

Finally, now that you managed to reach the end of the equation, our translations are definitely ready for use, and here is how:

POST Event with translations example

Get response by locale

If you don’t specify a locale, don’t worry! The fallback locale from the Symfony framework config will be used.

Get a response with all available translations embedded:

That’s all folks!

There we go, that sums up one of the easiest ways to implement translations into API Platform. All in all, if you have any questions or suggestions on how to improve translation implementation, feel free to let us know!

Also, it’s worth noting that if you need help with your API Platform, Sylius, or Symfony project, get in touch with us! We might be able to help with some of the problems, hopefully.

Originally published at https://locastic.com on Sep 25, 2018.

Having trouble with implementing translations in ApiPlatform? was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Is it possible to turn off the entire routes specification for the new Sylius API, and then include just shop Product configuration?

The question.

In order to keep our OpenApi(Swagger) documentation clean, we wanted to remove all unused endpoints (~150 routes exist by default). There are various ways of doing it, but hooking into ApiPlatform’s process of generating resources is one of the most powerful, yet simpler way of customizing the API.

The Solution

How does this work?

ApiPlatform has two services for extracting configurations from .xml and .yaml files registered as api_platform.metadata.extractor.xml and api_platform.metadata.extractor.yaml. By decorating them, we can control what our final configuration will look like.

Sylius uses XML for configuration, while we decided to use YAML, so this solution perfectly fits our needs.

After extracting all the configurations, ApiPlatform uses them to register routes. With this change, we ensure that the application generates only the routes and schema that we actually need.

Why would I need that?

We used a really simple example where we haven’t touched the $definition variable. It is an array that contains the entire definition for the given resource, so we can change it however we want (for example, this might be a good place to add “language” as a route parameter in the entire app).

Don’t forget, that this way of changing the API can be applied in any ApiPlatform application for various purposes.

Originally published at https://locastic.com on Feb 5, 2021.

How to switch off the ApiPlatform specification in the Sylius API was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Basically, you develop a login screen that allows the user to input their username/email and appropriate password and send a request to the server. If the server responds positively, that’s it. Your user is logged in. But the server returned one more thing: some kind of user identification you need to pass together with other requests to access certain data etc. Also, when the user closes the app without logging out, thanks to this we can keep him logged in and skip the login step every time the user opens the app.

It is either token-based authentication or session-based authentication. This diagram describes the main differences between the two:

Chart credit: https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide

As you can see, in cookie-based authentication, after successful login, the server creates the session and returns the sessionId value as Cookie. Subsequent requests contain that cookie with sessionId which is verified against sessionId on the server to determine if the session is valid.

On the other hand, we have token-based authentication. After successful login server returns the signed token. That token is then usually stored in local storage. Subsequent requests are sent together with the saved token in the Authorization header. The server decodes the token and if it is valid, processes the request.

Without further due, like the title states — this article will go through cookie-based authentication in React Native because it is not as straightforward as you may think.

The Problem

As you know, React Native relies on the native (Android and iOS) APIs written in Java and Objective-C. You may think the cookie usage is as straightforward as using it within the browser but unfortunately, it isn’t.

Native networking APIs save the cookies by default and it may seem perfectly okay at the beginning, but after some time and a few requests made, requests can become inconsistent causing the server to deny the access because the cookies we sent were invalid even though there is nothing wrong with them when they initially were passed along the request.

The Solution

The first thing that came to my mind is to take the cookie management into my own hands by simply storing them on the device (eg. Async Storage)

Now the flow goes like this:

1. after successful login, the server responds with the status and cookies
2. cookies are saved on the device (Async Storage)
3. each subsequent request’s Header is populated with the cookie from the device storage

And I thought this was the final solution. EZ right? But let’s see what the situation really looks like now.

It was working fine for a while but then the same problems started to occur and I was at the starting point again. As mentioned above, React Native has its own cookie management and now I implemented my own on top of it. Naturally, native API interfered with my implementation and won every time, overriding the cookie I sent with its own and causing the same problems to appear.

NOTE: I’m not 100% sure yet that this is what is happening on the native side.

After some research, I stumbled on the react-native-cookies. It’s a cookie management library for React Native and lets you manage cookies natively. Now there is actually a way to manipulate native cookie management, the approach to storing the cookie on the device can be further improved.

As already mentioned, native cookie management interfered with the stored cookies. So let’s completely remove native cookies and work just with the ones stored on the device. The easiest way would be to just clean up the cookies stored natively.

That’s where the above-mentioned library comes into play:

With natively stored cookies cleaned up before each request, it’s certain that the only cookies that are passed along the request are the ones stored manually on the device. Using this simple fix there are no more cookies interfering with each other and the main benefit is consistent sessions while using the app.

Wrap up

I spent a significant amount of time wrestling with this issue because it wasn’t so straightforward to figure out what seemed to be the problem. I decided to write it down so you don’t have to.

I think it’s worth mentioning that this is not the only possible solution to this problem because the problem itself is not fully investigated. There are also solutions without using any library which is described in this article.

Originally published at https://locastic.com on Jun 3, 2020.

React Native cookie-based authentication was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.

To sum things up, public speaking is nothing more than a confidence trick. Even those people that you admire the most probably sucked in the beginning because no one is naturally good at their first public appearance.

I might be a really good example to talk about the confidence part since I had my fears upon entering the speaking world and guess what — everything worked out well and I’ve done more than fifty events since then.

My speaking career kicked off back in early 2011. The first talk was featured at a local event in my hometown Split, which was a terrifying experience considering that I had to deliver my talk in front of people I actually knew. My palms were sweating, my voice shivered in the beginning, I feared the Q&A part, but once I got to understand the atmosphere and the audience, things started to get much easier.

Eventually, I survived the talk and all other things that followed, and the feeling of accomplishment forced me to do more in the future. Not just as a personal goal, but as a company CEO, I always consider conferences to be a great medium to showcase how we do things in Locastic.

Since then, I have spoken at more than 50 events all around Europe, and even one in Africa. During that period, I stumbled upon some basic questions and a few stereotypes about conferences and public speaking — so I decided to address them below. Let’s get it on!

“Public speaking is hard!”

It can be, but let’s change your perspective for a second. If you are getting ready to deliver a talk at some conference, that means that the first part is already behind you — the talk was submitted and accepted.

The second thing is that you know your topic and you know what are you talking about. Write down the whole flow of the talk, create the first version of your slides, and do a dry run in front of a mirror, or even better — try to record yourself.

After a while, you will notice which parts of your talk are better and which ones are not so good. Focus on improving those less pleasant and in no time you will see how much improvement you have. We can even compare this with your technical skills, or your code — the first iteration is always the worst, but don’t despair, things do improve over time (over a few iterations).

Don’t be scared. Everything is in your hands — you know the exact time and location of your talk, and there aren’t too many factors that can catch you off guard — analyze it, improve it, do the next iteration, and track your time.

“How to start?”

Start small, use every opportunity to practice, and eventually grow as a speaker. Every industry and almost every city in the world has a local initiative that actively works on growing the community. Some of them host meetups, others do workshops, but each one has the same goal — to spread the knowledge and to attract the community.

There’s your opportunity! Take some time to think and try to come across an idea of what you actually WANT to talk about, and then reach out to organizers. Be persistent, do that a few times, get some confidence, and start applying for events on a larger scale.

“What should I talk about?”

I keep hearing from people how they would love to try speaking but they’re afraid they can’t find a topic to talk about. Of course, you can! There is for sure one thing that you are passionate about in your work.

Everyone has a certain interest or a hobby that is worth talking about. It can be a project, a situation that happened at work, or a new technology stack — whatever. Just make sure you talk about something you’re excited about and want to share it with other people. Pick yourself a topic that you are passionate about and you’ll do well. I guarantee it!

“What if something goes wrong?”

Well, public speaking is not easy for sure, and it is not the same for all people. For some, it’s natural, but for others, it can be the hardest thing ever. Like, you need to go in front of really critical people and talk about a certain topic — there is a lot of risk involved.

“If you can’t explain it to a six-year-old, you don’t understand it yourself.”

Albert Einstein

But if you think things through, you and only you are absolutely in control of the talk that you will deliver. You choose your own topic and hopefully, you’ll decide to talk about something in your area of expertise. The main premise is that people attend your talk because they want to learn something from you and once you grasp that — it’s an amazing feeling.

It’s simple — you know the exact time, location, and all other factors that can help you prepare. Practice as much as you can, be innovative, and create different scenarios, trust me — after the talk, a lot of people will approach you and start asking questions.

I see post-event networking as the most important part of the cycle — always take notes and try to improve your talk for future iterations.

“Prepare, don’t improvise.”

Why not a mixture of both?

Improvisation is another great skill that you automatically improve if you start speaking on a regular base. There is no speaker in the world who hasn’t been in a situation where they were not 100% prepared and they simply had to do some improvisation.

To be honest, I think improvisation is an amazing skill and I definitely enjoy listening to speakers who do live on stage improvisation. Don’t get me wrong, seeing an unprepared speaker is the worst thing ever, but those people who get away with it are the most impressive ones as well.

So, in the same way you learned to write decent code, you can also invest the same amount of time in improving your speaking and communication skills. Your speaking life will be much more interesting once you see there is nothing to be scared of.

“Embrace the fear.”

According to quite a lot of studies, people’s number one fear is public speaking, and number two is death.

Death is number two. Does that seem right?

Well, that’s just how it is. Public speaking is not easy, just like with every other activity that includes emotions. It moves you out of your comfort zone, it can be stressful and it involves a lot of sentiment. And don’t forget that being fearless is not about eliminating the fear — it’s about mastering it!

It’s all about taking that fear and transforming it into excitement and energy around the message you are trying to display. If you focus on your talk in this way, you will feel amazing excitement and happiness right after delivering it.

But also, after some time you will probably feel very tired and exhausted. It’s because you put all your emotions into the talk itself. That is probably the best sign that you did a good job and put yourself completely in that adventure.

“It’s impossible to find a proper mentor.”

Public speaking is an active skill; recently we’ve seen schools and programs emerging around this trend. Some people have talent before they even start, but most of the speakers had to work their way up through dedication and practice.

Also, many conferences and communities (Symfony, for example) host initiatives to mentor new speakers for free. So, as a first-time speaker, or even as an experienced one, you can get free training sessions on how to improve your talk. Amazing, isn’t it?

Yes it is, and that is the same community that is attending your talk — they are there to learn and to help you improve it in the future.

There will be some situations when you will get average or bad reviews for your talk, but don’t allow this to have a bad effect on you. Read them, analyze your talk, write down mistakes, and fix them for the next talk.

When I started my speaking career, I struggled with watching or listening to my own talks and I bet that most speakers hate that too. There’s just something weird about listening to your voice, right?

Moreover, that is now actually the first thing I do after receiving a recorded session/talk. And what I do is watch the recording, search for mistakes, and later on try to improve for the next talk. I simply think that this kind of action is the most effective way to make gradual improvements.

Still not convinced? Maybe these few tips can help.

1. Build your talks on top of your experience instead of basic how-to-start tutorials.
2. Stand up when you practice — don’t sit or lay down.
3. Don’t over-rehears, that can sound fake.
4. Ask other community members to review your talk, most people will do it for free!
5. Nail your intro to immediately showcase a sense of confidence.
6. Always thank the organizers, they are the ones making things possible.
7. Make yourself available to attendees after the talk is delivered.
8. Take notes and implement your audience feedback for future talk iterations.

Public speaking will for sure force you to push your limits. First and the most important thing that you will need to learn and get to know is how you act under stress and pressure. An example of regular stress could be a simple dysfunction of your mic or computer, and you’re in front of 500 people.

That might have a huge effect on how you are handling stressful situations, not just in this industry — but on a daily basis too.

Stay calm!

I consider myself as an extroverted person who loves to meet new people and who loves spending time being surrounded by people. I know this is not a situation for most people (developers), but for introverted people, there is no better advice than just going out there and delivering THAT talk.

I personally learned that I experience a certain emotional pattern before each talk and I won’t lie to you — I still feel stressed as hell before heading over to a stage. However, as soon as I reach it, I forget about fears and my only focus becomes delivering the best possible talk ever.

That kind of experience reflected in my everyday life as well making me learn to control the situation better and to stay calm under pressure of any kind.

Ultimately, don’t be scared to get out of your comfort zone.

This last advice applies for a bit later when your speaking eventually kicks off. Once they succeed and start delivering more and more talks, some people are struggling to get out of their area of expertise.

That’s just a fact — individuals tend to remain within their comfort zone because it prevents them from having to engage in new activities that they might find scary or intimidating.

Most of my talks were technical talks, but in the future, I want to focus more on team management and business talks. My humble opinion is that we as an industry are outstanding at writing solid and sustainable code, but we suck at managing projects and people. I think I can contribute a lot to fixing this.

Have you already delivered your first talk or you are planning to do that?

Originally published at https://locastic.com on Sep 19, 2019.

Are you afraid to speak in front of an audience? was originally published in Locastic on Medium, where people are continuing the conversation by highlighting and responding to this story.