Did you know that Google developed the first versions of Twitter and other popular apps on Android with no strings attached?

According to Sara Beykpour, a former Twitter employee and the company's second Android engineer, "

The Twitter for Android client was a demo app that Google had created and gave to us.

" Twitter then took this foundation and continued to develop it into the robust platform it is today.

Of course, these designs are now about as current as your grandma's flip phone, but back then, they were top-notch.

When designing your app, always keep the user in mind. Prioritize seamless navigation, intuitive interfaces, and quick access to key features. Regular UX testing ensures your app is user-friendly and meets your audience's evolving needs.

Analyze support tickets to identify the most frequent requests and find common patterns instead of addressing each issue individually. Spending 20% of the time replacing a whole section of the app can eliminate 80% of your users' problems.

Integrating your app with widely used platforms and services can enhance its functionality. APIs from social media, payment gateways, and cloud services can enrich user experiences and expand your app’s capabilities.

Sharing your progress and insights gained in the process on social media platforms will drive engagement and traffic. Posts detailing the journey and steps taken to achieve milestones often go viral, making social media a top source for sign-ups. A single viral post on Reddit can increase traffic tenfold overnight.

Incorporate AI-driven features to personalize user experiences, provide intelligent recommendations, and automate customer service. Tools like TensorFlow, Azure AI, and AWS Machine Learning can help you add these advanced features.

Ensure your app runs smoothly on all devices. Focus on speed, reduce load times, and test across various hardware and network conditions. Performance optimization is crucial for maintaining a positive user experience.

As Google did with their early app development efforts, be prepared to go above and beyond to make your app successful. This might mean providing extra features, offering exceptional support, and continuously iterating based on user feedback.

If your business needs a cutting-edge app and Google is no longer giving them away for free, don't worry—we've got you covered at a reasonable price. 

How Google Crafted the First Twitter Android App

 (the creator of GoAWK) for being really patient and helpful throughout my contribution process, providing thorough and insightful code reviews.



 is a measure that tells how much of your source code is executed by tests.

 is a task/command runner that I’m developing. It’s sort of similar to the well-known make tool, but without most of its idiosyncrasies (and with a couple of unique features!).

It may sound surprising, but I wrote it in AWK. I won’t lie: writing it in AWK started more out of curiosity than out of real need. To me, limits encourage creativity. Few people know nowadays that AWK is a full-fledged programming language, though really minimalistic.

Makesure started more like an experiment to see how far writing a tool in AWK can go. It appears to be pretty far. I don’t think this is an exception, but rather a consistent pattern, due to the true genius of the AWK authors.

To take an example from another project written in AWK:

!
To bytecode; I wanted to use the awk-based compiler as the initial bootstrap stage for a self-hosted compiler. Disturbingly, it worked fine. Disappointingly, it was actually faster than the self-hosted version. But it’s so not the right language to write compilers in. Not having actual datastructures was a problem. But it was a surprisingly clean 1.5kloc or so. awk’s still my go-to language for tiny, one-shot programming and text processing tasks.

The other idea behind choosing AWK for Makesure is the ease of parsing. For example, when parsing this Makesure syntax:

If you know a bit of AWK, you understand that this syntax is fairly easy to parse with it. AWK already does word-splitting for you, so all you need is this:

Essentially, using a limited tool for the job (AWK) motivates you to comply with the 

 principle, which I’m a big proponent of. You don’t invent fancy syntax, but rather rely on syntax that can be parsed in a straight-forward way.

Time passed, and the source code for Makesure grew to a 

, but I was not sure how good the coverage was, whether all critical scenarios were tested or not.

Thus the need to test coverage 

. My research revealed that no AWK implementation had a code coverage facility. And so I decided to add one to an AWK implementation. The most suitable for such an addition appeared to be GoAWK.

Of course, some of my other motivations were practicing my Go and AWK programming skills.



Essentially, to collect code coverage statistics, we use source code instrumentation. That is, each line of code is annotated with a piece of tracking code (details below). Thus, when the instrumented program runs, the tracking code is triggered each time a code line is hit. At program completion, all collected coverage profile data is written to a file. This file is then used to create a human-friendly coverage report like the one below:

How code coverage for AWK differs from mainstream languages

 tool. It provides a really nice and simple way to test a CLI tool as a black box.

The tests in 

 and simply compares the actual output with the expected output using a normal diff. If there is a difference, the test fails and the diff is displayed to the user.

In essence, such tests are end-to-end tests that are on the top of the well-known 

. This is very good, since this style of testing is equivalent to how a 

user uses the tool, giving a much higher chance of catching 

bugs.

Using this approach, I created a comprehensive test suite for Makesure, with a typical test file 

.

The usual approach to testing (like in Go, Python or Java) is to create a set of tests (usually in multiple source files), then to use a “test runner” to run all them at once. And there lies a subtle but important difference from the approach described above.

In the case of a test runner, you run it once for all tests, so it can form the overall coverage profile when all the tests are completed.

In the case of 

 underneath) is called many times with different arguments. Which means we want a way to assemble the final coverage profile incrementally.

This poses additional implementation challenges. We need the ability for separate runs of an AWK program to be able to append to a single coverage profile. This implies that the internal format of this file needs to be “appendable”, but also requires that the reporting facility that consumes the file understands this “appendability”.



A couple of years ago I came across the article 

. The article was pretty insightful for me, as it gave enough technical explanation, and described typical challenges when implementing code coverage for a particular programming language.

The author based his implementation on the 

 coverage tool, initially targeted to JavaScript. But the author managed to generate coverage profiles for another language (Solidity) in Istanbul format, allowing him to reuse the reporting facility of Istanbul for free.

My plan was to use a similar approach. But my research showed that the Istanbul 

 was not append-friendly.

The other direction of my thought was defined by the classic book 

 by Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger (the A, W, K of AWK). As an aside, this book is an absolute pleasure to read and amazingly relevant today, despite being published in 1988.

On pages 167-169 of this book is section “7.2 Profiling”. It describes a very simple approach to how one can implement the profiling of a program with just two AWK scripts: 

 (they’re just a few lines of code each!).



 does (admittedly naive) transformation of the input source by inserting a statement of the form 

 clause that outputs the collected statement counts in 

 attaches the statement counts from this file to the original program and displays the counts together with the original source code.

I was completely fascinated by the simplicity and clarity of this approach!

Despite the fact that this approach is far from perfect and practical, I really considered using an improved version of this approach. However, it was clear that to make it more precise and robust, I’d need to transform the AWK program’s AST (abstract syntax tree), not just perform a naive source code modification.



While working closely with AWK for my project, one day I came across GoAWK. Out of curiosity I tried running Makesure with it. This revealed some bugs in GoAWK, which I reported, and they were fixed promptly by Ben Hoyt, the creator. So eventually GoAWK passed the test suite of Makesure.

At that time I started getting interested in learning the Go programming language. So I was happy to contribute and fix some minor bugs I encountered. Overall, I really liked the GoAWK project and especially the author behind it. I can’t help but recommend 

 – very well written and interesting.

So I thought that whatever implementation approach I choose, I would like to use GoAWK as a base. Since GoAWK was written in Go, I decided to take a look at the coverage support in Go itself. This was when I came across Go’s 

. I was immediately convinced!

The functionality was not as advanced as Istanbul’s, but still enough. The implementation seemed to be relatively simple. But most importantly, their coverage profile format appears to be designed with appendability in mind! (Though, to my knowledge, this feature is not directly used by the Go tools themselves).

So I decided we should add code coverage functionality to GoAWK, but use Go’s coverage profile format, so that we could reuse the Go machinery (

To better understand what follows, it may be beneficial for the reader to first read 



GoAWK uses pretty standard patterns in programming language implementation and execution strategy:

 1. Firstly, the input AWK source (as a string) is processed by the 

 2. Then the list of tokens serves as input for the 

, the output of which is an AST (abstract syntax tree).

 that was initially part of the parser. It analyzes the AST and annotates it with some additional data, like information about variable types.

, producing a list of opcodes and their arguments – the GoAWK bytecode.

 4. Finally, the bytecode serves as input to the 

, which has a Virtual Machine inside. It runs the opcodes instruction by instruction to execute the program.

Now I needed to understand how to fit the code coverage functionality into this scheme.

As I explained earlier, we need to instrument the source code for coverage tracking. It’s much easier to explain using an example:

Given the following AWK source:

the instrumented code will look like this:

It was obvious that this tracking code insertion should take place at the AST level. So I imagined we’d need to add an additional step between 2 and 3: it would take AST as input, pass it through a “coverage annotator” (yet to be added), and produce the transformed AST.

But it wasn’t so simple in practice! The main problem was the tight connection between the parser and resolver. In fact, both of them happened in the same pass, so it was impossible to run them separately.

Let me explain why this is important. If I just changed the AST by adding the required nodes for the 

 statements, those new nodes would lack some tiny (but important) pieces of information filled in by the resolver. So somehow I needed to run the updated AST through the resolution step once again. But this was technically impossible, because the resolver (being part of the parser) could only consume what the parser consumes – that is, the list of tokens.

So, I thought, why not just render the modified AST back to AWK source and then start the whole process from step 1. Luckily, GoAWK already had a 

 implementation for all AST nodes, so it could render AST back to AWK source. Unluckily, this AWK source 

was not guaranteed to be correct in all cases

, because its purpose was to output the parsed AST for debugging (the 

 flag).

This is when I added the first dirty hack: I patched the instrumented AST (more precisely, the inserted pieces) as if this was done by Resolver itself.

The second hack I used was even nastier. When I inserted coverage instrumentation like so:

I also internally store the information that describes it, such as the filename and source lines being covered. This information is captured in the 

So internally we have the following (Go pseudocode):

Storing this data is needed for building the resulting coverage profile (in the format used by 

Each line above describes collected coverage for some block of code, and has the following format

Now, remember that you can run AWK with multiple source files, like so:

But GoAWK, in step 1 above, just joined all source files into a single string and used that as input to the lexer.

This means that by the time we’ve got the AST after step 2, there is no way to tell which AST node came from what input file. Thus, we aren’t able to fill in the 

 during instrumentation.

So to pass the required 

 information to the AST, it needs to wire it through both the lexer and parser, I thought. For this I introduced a 

 that I inserted at the start of each file. Thus, when sources were joined, this token represented files boundaries, which meant that at parse time I was able to track the filenames and local positions in each file.



Although the approach worked well in practice, it was clear that it was ugly, and that it had zero chance to be merged as is. Ben came up with a 

 about structural things he’d like to see addressed before merging this in.

There was no other way than to undertake a couple of serious refactorings before we attempting to merge my code coverage support.

Frankly, I was not upset at all, but rather excited! Firstly, I got a chance to do even more useful work for a project I liked. And I was glad to keep sharpening my Go fu further.

The biggest thing to start with was decoupling the parse and resolve steps. This was a bit scary to touch. Even Ben described this part of code as follows:

In fact, the resolver was one of the harder pieces of code I’ve written for a while. It’s the one piece of the GoAWK source I’m not particularly happy with. It works, but it’s messy, and I’m still not sure I’ve covered all the edge cases.

But I think I understood how it worked overall, and how I could do the refactoring. Reading Ben’s tech writing was a big help.

I needed a way to traverse (and update) the AST for the resolving step after parsing.

For this 

. Once the visitor functionality was in place, the AST traversal needed for resolving 

 served the purpose of resolving global positions in the joined source code back to local positions in the input source files. This was needed to get rid of hack #2 mentioned above.

When both the refactorings were reviewed and merged to master I was able to submit my 

final clean implementation of code coverage

 on top.

Overall, I highly recommend this approach to big contributions. You should not try to fit all your changes into a single pull request. Each PR should be highly cohesive, that is, solve only a single problem. That is much easier for the project owner to review and accept such PRs. Also, such PRs will be valuable on their own, even if not all of them manage to reach the master branch. As John Ousterhout says, 

problem decomposition is the most important idea in all of computer science

Running GoAWK coverage on Makesure revealed 

. This helped to find a bug (which has already been fixed).



As I’ve mentioned, Go’s approach to code coverage is not very advanced. It implements 

coverage (the same applies to GoAWK coverage). For simplicity, 

. Other coverage tools, like Istanbul can provide more detailed coverage, like coverage for 

.

To illustrate that last point, let’s imagine this code:

You can have it all green, but still something is not covered: the implicit “else” branch is not covered. In other words, we want to make sure both true and false variants for 

 are covered.

It would be really nice to improve this for GoAWK coverage and maybe even for Go itself, but I’ll leave that for future work!

The Go Blog: “The cover story” by Rob Pike

 – the book by the AWK creators, a must read!

Code Coverage for GoAWK

My research revealed that no AWK implementation had a code coverage facility. The most suitable for such an addition appeared to be GoAWK.

As a startup founder in today's rapidly changing times, you might be overwhelmed by the numerous tasks that arise after your brilliant idea comes to mind. The most important ones include testing your idea and bringing value to your end-users as soon as possible. Outsourcing software development could be the most suitable solution in such cases, especially if you lack expertise in development or don't have enough time to manage this process due to your main business.

In this easy guide, we'll help you explore outsourcing programming for your startup, showing you how to start, pick a good partner, and dodge common mistakes new entrepreneurs make.

First, let's define what you can outsource:

Developing the entire app from start to finish could be both mobile and web applications. See more about our SDLC.

Specific tasks include UI/UX design services, DevOps services, or developing any part of your software product.

Requesting a company to provide you with a reliable programmer to join your team as an outstaff specialist or consultant.

Unlocking the Power of Outsourcing for Your Startup

Outsourcing programming is a significant part of the IT industry. In 2023, it's anticipated that the IT outsourcing segment will generate a whopping US$430 billion in revenue (

). Even big companies like Google have recognized the benefits of outsourcing programming tasks. These benefits include:

Quick access to specialized skills without investing in training or hiring new staff.

Established and automated business processes and workflows.

Increased flexibility, allowing you to scale your arrangement as needed without worrying about hiring or firing staff.

Reduced risks associated with staffing and operations, including turnover, training, and compliance.

How to Maximize the Benefits of Outsourcing Programming

We'll provide a guide to help you with everything from choosing the best vendor to launching your product, aiming to ensure a great experience for your startup's partnership with an outsourcing company.

Define the Most Suitable Employment Model

If you are ready to manage the whole process or already have an established team, hire one or more outstaff developers to augment your team. This approach requires more time from you to describe tasks and manage the process, but you won't have to pay for an external manager.

Another popular model is hiring a dedicated team with developers, project managers, QA specialists, designers, and other team members on board. Depending on your expertise, you can discuss and select the necessary team members. If you hire a team, you must choose the most appropriate model, such as Time & Materials or Fixed Price.

If you only need to augment your team, identify your requirements for each team member, such as programming languages and tools. If you want to hire a team, define a project description with a shortlist of features to help you communicate with the outsourcing company.

Outsourcing companies are located in different countries, allowing you to find the perfect fit. Consider factors like cost, language, cultural compatibility, and time zone. Eastern Europe is a popular region because developers have a good English level and excellent hard and soft skills that enable them to work with team members from different countries.

Now you can move on to defining a shortlist of companies based on your requirements and preferred location. Using platforms like Clutch or GoodFirms is a simple way to find potential partners, as these platforms provide lists of companies with verified reviews from real customers. Additionally, take your time to conduct Google research and investigate company websites to check their portfolios. If a company has already completed projects like yours - they can likely do it faster and with less risk than their competitors. Once you're confident that a company suits your needs, contact them with an inquiry about their services.

After examining past projects and client feedback, ensuring that the company has a solid track record in managing the required IT services, it's time to arrange interviews with shortlisted candidates to assess their hard and soft skills. The management team represents the company, so pay attention to their focus. Good service companies are centered on bringing value to your projects, so expect many questions, particularly if you haven't provided detailed requirements upfront.

If a company just gives you a rate card without asking questions, be careful, as it may lead to misunderstandings down the road.

If you need developers but don't have tech experts around, it could be a good idea to hire developer from another company just to o the interview or look up popular interview questions online and ask a couple during your search. You can compare the answers and pay attention to how developers communicate with you and whether they are confident in their responses.

When you've found the perfect match, prepare an agreement with your lawyers or use an agreement from the service company. Remember that both parties have had various positive and negative experiences, so a well-drafted agreement is crucial for successful collaboration. Moreover, if an outsourcing company has a well-prepared agreement, can provide accurate estimations and explanations, and their documents have a user-friendly interface, these factors serve as additional reassurance that you've made the right decision.

By following this comprehensive guide, you can effectively navigate the world of programming outsourcing for your startup. Outsourcing has lots of advantages, like saving money, reaching global experts fast, easily scaling, and cutting down risks. By carefully choosing the right partner, specifying your business needs, and actively participating, you can ensure a successful collaboration that brings your startup's vision to life.

You've come to the right place if you're searching for a proficient outsourcing company catering to your business's diverse IT service requirements. With years of experience delivering global programming services to businesses, we're equipped to assist you with any emerging IT-related needs.

, and let's explore how software development outsourcing can enhance your business!

How to outsource programming in 2023: A comprehensive guide for startups

By following this comprehensive guide you can effectively navigate the world of programming outsourcing for your startup. 

Let’s consider the most popular options for adopting blockchain for retail companies. All the possibilities suggest that we can build the system from scratch or make a bridge between the existing solution and a new one for the first time. Moreover, it allows for reducing costs and testing hypotheses safely.

Blockchain is the ideal tool to build something more significant than the outdated encouraging methods in other retail companies.

We can build a genuinely gamified micro-economy among the company workers.

The first step is to create your crypto assets that can bring value by themselves,

Further, the manager can set up the rules that control the rewarding system, for instance: employee rating - where each employee can reward another with a special NFT, monthly sales - when an employee overcomes such a limit, they get a crypto token for the reward, consumer rating - when a consumer can not only say thank you but gives a bonus to the employee via two clicks on the mobile app.

An internal point system gathers all the information and allows one to understand the current situation and foresee future employee behavior.

Employees have complete control over their tokens, so they can buy goods in the internal store, trade tokens for money, or transfer them to each other as a reward for performing particular tasks.

Brand loyalty has always been one of the keys to success for retail businesses, especially nowadays after covid.

There are a few ways to improve your loyalty program:

Charge crypto tokens for buying goods in the store and allow you to pay with these tokens in your store or affiliate networks.

Create an NFT collection associated with your loyalty program. For example, it could be 10,000 unique cartoon pictures with different designs that the clients can sell in the future.

The retail application can convert monthly cashback rewards to popular crypto such as BTC, ETH, etc.

Consumers can donate their tokens to some charity organization from the affiliate networks.

The last but not the least option is creating the cash app with a debit cash card. Each time the users pay with the app, they receive some percent cashback paid out in internal tokens or popular cryptos like BTC and stablecoins.

Tokenization is an updated version of traditional fractionalized property ownership in the real estate business. We can adapt this approach to the retail industry and attract more investment to open a new store or to expand an existing one.

The idea is simple - you can just convert your store into digital tokens; everyone who buys those tokens becomes an investor in your property and own a portion of the equity. Furthermore, the system can obligate each investor to pass through the KYC (Know Your Customer) process for authorization and ask additional questions before allowing them to buy tokens.

In their turn, investors get passive income via affordable investment.

Control the whole supply chain to prevent counterfeit goods and fraud; also, it builds transparency and allows end users to know where their order is and your employee to organize the proper inventory management.

You can allow the use of crypto as a payment method in your store.

There is also a way to provide direct person-to-merchant transactions and allow clients to receive distributed loans within your society.

Crypto assets are smartcontracts-controlled objects that exist only in a blockchain network and can prove ownership and provide transfer functionality. If the object initially wasn’t a digital asset, it could become one. For example, you can convert a photo into an NFT or create tokens representing the property's ownership.

There are two popular types of digital assets:

Cryptocurrency - fungible token, like a reward point

NFT - unique and not mutually interchangeable cryptographic token like an art object or branded T-shirt for a client’s metaverse hero or another personal gift.

One of the obstacles on the way to absorbing blockchain is necessary to install and set up crypto-wallets, understand how blockchain works, etc.

The mobile application eliminates this issue because the app works like a wallet. Different options depend on the market: check employee rewards and transactions, make a gift, chat with each other, buy, send and receive crypto assets. In addition, the app can transform the phone into a physical loyalty card through integration with NFC.

The control center is a web application that provides all necessary functions to set up, observe and control the system.

There could be a variety of subsystems such as:

Program manager: The primary tool for creating and adjusting the different programs such as the Loyalty program, employee recognition program, etc.

Block explorer: an engine that enables everybody to retrieve real-time and historical data about transactions, addresses, and more.

Token builder: service for deploying and controlling tokens, including minting, burning, etc. Here admin can create new badges, for instance.

Analytics: an engine that allows monitoring of all the system’s metrics via charts on the main dashboard. You can inspect in real-time how your consumers, partners, or employees are reacting to different incentives and a variety of options for report generation.

Alarms: triggers that inform responsible persons about some unusual activity etc.

Blockchain in Retail: Use Cases

Blockchain technology allows retail companies to incentivize customers, employees, and partners.

At CML Team we are building our own (yet internal) CRM system. Technology-wise, it's a traditional web application with Java + Spring Boot + MySQL on the backend and React + Next.js on the frontend.

We have pretty good code coverage for the backend (reaching 80%) with tests, but the integration tests are (as expected) rather slow. It takes 20+ minutes to run on CI server. It's even slower running locally.

Needless to say, this slowness renders tests much less useful and helpful for the developers, since they practically can't run the tests locally often enough.

At CML Team we value integration/functional tests. So we tend to write tests with less mocks, tests that span all layers of the (Java) application (controllers, services, repositories) -- down to (and including) the DB. The tests run on a real database (MySQL), not on often recommended H2.

Overall, the idea is, the closer your tests follow 

 application setup, the higher are the chances to catch 

Of course, we write unit-tests when applicable. But otherwise, we prefer end-to-end tests to tests for a specific controller, service or component.

It's clear that such tests are inherently slow, but they should not be 

 slow! It was time to take a deeper look to understand what's going on.

Let's take a look at typical test we had there:

As you can see, this test has the following logic:

Firstly, it wipes the DB and fills it with initial data in 

@CleanDataBaseBeforeAndAfter(".../init_data.json")

Then, it runs the body of the test method, that executes a REST call to the API being tested

Finally, it tests the correctness of the final state of the DB via 

It appears that this test takes whopping 8+ seconds to execute:

And if we take some thread dumps during the execution, we can see, that major part of this time is spent in the Database Rider plugin applying the initial state to the DB (

I have some guesses why this can take so long:

 into a set of SQL inserts the Database Rider must determine the correct insertion order, according to entity relations (like foreign keys). So I guess, as part of this routine it needs to first fetch the whole database metadata, and then apply some topological sorting to the source dataset.

I'm not quite sure, how efficiently does the Database Rider do the inserts. Whether it is in an auto-commit mode? Whether it does each insert in a separate transaction?

 is shared among multiple tests, it, probably, contains more data than needed for this particular test.

Given the concerns above, the rewrite strategy was obvious. Get rid of Database Rider annotations and code the DB initialization and DB check steps in plain code.

So now instead of having implicit logic, hidden in annotations we have it in code, in the 

 encapsulates the functionality of cleaning the DB and starting/committing the transactions, common for many tests:

 is to generate the testing data records in the DB. So by default it should generate the same entity data for any test, but should also provide a common way of customizing each entity instance before creation (using 

Using this design you can pre-populate the testing data set in any way you like in the most concise way:

 also uses a small trick of not using all the specific repositories for each entity type (like 

, etc.), but persisting through a lower level 

 fixture reuse. This makes it less efficient due to excessive data not needed for a particular test. Besides, tests now tend to rely on the same (or intersecting) data, making it harder to change this data for a particular test.

Secondly, tests are now self-contained, not scattered over multiple files, like with DB Rider. This makes the test logic more comprehensible.

Thirdly, it's easier to debug and profile this way. Also, you only create the minimum test data you need for a test.

Lastly, you have more opportunities to refactor, less copy-paste.

To illustrate the last point, let's take a look at the set of (repetitive) tests we had before the refactoring:

So far only 40 integration tests (out of around 490) are refactored this way.

And believe it or not, we also were able to delete over 3K+ lines during this change (mostly due to dropping the fixture files):

In the near future we plan to rewrite the rest of the tests and use this approach for new tests.

Rewriting Spring Boot integration tests for 10x speedup

How to drop the execution time of integration tests from 4m 30 sec to just 20 sec? Let's figure it out.

How Google Crafted the First Twitter Android App

Key lessons for startups in 2024

Other blogs