DEV Community: Rytis

NFTs, Blockchains, and Standards Explained without BS

Rytis — Fri, 28 Jul 2023 11:43:11 +0000

This was originally written for my colleagues who were working on a same project. I am definitely not a cryptochad or a crypto promoter, but I find this technology quite interesting. If you want a no BS explanation without the hype or something being sold to you – then read on. This is the explanation I wish I had when I’ve started researching this technology. Please comment on any misconceptions / mistakes.

What is a Token / NFT

First we need to clarify some terminology. NFT stands for Non-Fungible Token, however people just use it as a catch-all term for everything crypto. What is the difference between fungible and non-fungible tokens?

Think about a fungible token as just a simple 50 cent coin in your wallet. It is no different from any other 50 cent coin, and you probably don’t care whether you have that particular coin, or any other 50 cent coin. They are the same, they are interchangeable – they are fungible.

Non-Fungible, however, means unique. Think of it as a commemorative coin with a stamped serial number. You might own the coin with the serial number 001, and your friend might own a coin with a serial number 050. They might look similar, but are unique because of their serial number. You wouldn’t exchange a 001 coin for a 050 coin, unless 050 had more sentimental value to you than 001.

Technical Workings of Smart Contracts

Another very important thing to understand is how smart contracts work and what they are. Smart contracts are just code that runs on Blockchain, that’s it. There’s no magic involved. It’s not much different from a Java class. Smart contracts are written in Solidity language, which is a Turing Complete language, which means that pretty much any programming goal can be achieved with the language.

However, there is a caveat – each operation on blockchain takes a very long time and can even cost money, so huge and complex functionality may not be feasible. Great care must be taken when developing smart contracts to reduce the complexity, operations, and thus the cost of execution. A cost of execution is referred to as Gas Fees.

Smart Contracts can also store data (for example token ownership information) on the blockchain. This costs even more Gas.

Views vs Transactions

An important distinction should be made between views and transactions. Retrieving data from blockchain (such as user’s crypto balance) does not warrant any gas fees from the user. As far as the end user is concerned, retrieving and showing data from blockchain is free. As long as no data is altered, the operations are free. To call a view function, user does not need to sign anything, the data will just be returned.

Storing, manipulating, changing the data on Blockchain, however, is not free. Data manipulation on blockchain is called a transaction. If any data is being changed (such as changing the owner of a crypto token), then all operations done within the same transaction will incur Gas Fees. Different operations have different gas cost – adding two numbers together is cheaper than making a call to an external smart contract. User will also need to sign the transaction, which basically means that before the transaction is executed, user will see a prompt from MetaMask and will have to confirm the transaction.

All transactions are public. Everyone can see who made the transaction and what data has been changed and when it happened. Gas fees and any crypto transfers are also visible to the public.

Transactions also come in two flavors – payable and non-payable. A payable transaction means that some amount of chain’s native currency (Ether on Ethereum, and Matic on Polygon) is attached together with the transaction. How the currency is distributed is in the sole discretion of the smart contract. A good analogy would be: you take an envelope and put in a note with the instructions and you also add a couple of dollars in that same envelope. The receiver of the envelope reads the instructions, and then gives a couple of dollars to their boss, takes a dollar to themselves, and then sends a dollar back to you. The postal fees you have paid to send that envelope are completely separate (analogy for gas fees). Money added to a transaction is referred to as transaction value. Transaction value and gas fees are absolutely separate and unrelated. A non-payable transaction will incur gas fees anyway: again you’re paying for the postal office to send your letter, you’re just not adding any bills in the envelope.

Smart contracts in terms of crypto tokens

A crypto token, be it some coin or an NFT – is a smart contract. Tokens have different standards, with different functionality and different goals, and those will be explained further down the line. Token contracts store their ownership information inside themselves, which means that from a technical perspective, saying that a token has been added to a wallet is incorrect. Technically nothing ever gets “added” to the wallet. The contract stores a wallet token balance inside itself, so the more accurate description would be: “Wallet gets assigned a balance in the contract”.

This is extremely important to understand, because this part is where most miscommunication happens, with regards to crypto tokens.

A word on immutability

Immutable means unchanging over time or unable to be changed. Smart contracts are immutable. This means that once the contract is deployed on blockchain, no one can change the functionality of it. Data stored by the contract can still be manipulated, granted that the functions to manipulate that data were developed, but you cannot add or remove those functions.

This brings us to the biggest pitfall of smart contracts – they need to be developed correctly from the start. If a security vulnerability is later found in the contract, there’s nothing you can do about it. This is one of the reasons a lot of famous hacks have happened.

So how can one upgrade the contract functionality? The answer is – deploy a completely new and separate smart contract with new functionality. This means that this new contract has new data completely unrelated with the previous contract. And that’s where we enter migration territory.

Contract migrations

The moving of data from one smart contract to another is called a migration. There’s no standard way to migrate the data, if it is possible at all. When smart contracts are developed, any future migrations should be had in mind upfront. If no functions were developed to read the data in the smart contract, the migration might not be possible at all.

Technically a migration might happen as a communication between old contract and new contract:

New Contract: Hey, old contract, how much of token 1 does wallet 0x123 have?
Old Contract: 42
New Contract: Ok, then I’ll note in my storage that wallet 0x123 has 42 counts of token 1. Hey, old contract, how much of token 2 does wallet 0x123 have?
And so on…

This can get expensive pretty fast. Remember, each storage procedure costs gas. The more distributed your token gets, the more expensive it will be to migrate.

A way to save gas fees in case of migration, would be to offload the costs to your users. This is more of a communication exercise, rather than a technical challenge. A functionality to copy the balance of the old token to the new token contract could be developed and your users could be told to call that functionality themselves, and pay the gas fees. This could however frustrate your users.

Another thing to note is that after the migration, your old token contract, together with its ownership data will still be on the blockchain. This means that users that have migrated the tokens will still have their tokens in the old contract, as well as their tokens in the new contract, thus duplicating the information. Unless, of course, you develop a functionality that burns the tokens in the original contract.

Differences between blockchains

Nowadays there are a lot of different blockchains. Ethereum is the most popular blockchain, but there are others, such as Polygon. However, most of those chains are just a copy of Ethereum, which means that they use the same language and principles for smart contract development, which in turn means that smart contracts developed for Ethereum will work on Polygon or most other chains without any changes.

Even if smart contract code is the same, contracts deployed on different blockchains will have nothing in common between them. If you launch your token on Ethereum and Polygon, they will not share ownership data, limits, metadata, or anything else. It’s like having two different Volkswagens – one on Earth and another in Mars. The blueprint is the same, but they don’t interact with each other.

It is also important to mention that Bitcoin is a whole different beast on its own. It’s not based on Ethereum and cannot run the same smart contracts. Forget Bitcoin, it does not exists as far as we’re concerned.

Token Standards

So what are the options for token standards? A couple of standards are defined in the ERC (Ethereum Request for Comment). I encourage you to read the mentioned ERCs, so you can have the information from the horse’s mouth, but I’ll try to quickly run through the standards in my own words.

ERC-20

Read EIP

Your most common fungible token – a shitcoin, pardon the expression. All those Pepe Coins, Shib Coins, etc are ERC-20 tokens. It’s supposed to be like a currency, like your dollars and euros. You could also look at it as stocks – pieces of a company (you can cap the supply of the coin for artificial scarcity). No matter how you look at it, a piece of ERC-20 is the same as any other piece of that same ERC-20 token.

The ownership data is stored as a map of Wallet Address → number of coins owned:

Wallet 0x123 owns 3 tokens,
Wallet 0xABC owns 7 tokens,
etc

ERC-721

Read EIP

The most common non-fungible token, the original NFT. This is also sometimes referred to as collection. A collection has a name, such as “Bored Ape Yacht Club”, and it also has a ticker symbol, such as “BAYC”. BAYC, by the way, is a real token collection, where you can collect apes. Each ape is different from another (non-fungible).

Each NFT in the contract is identified by a unique ID. This number does not change for the life of the contract. The ownership information is essentially stored as a map of Token ID → Wallet Address: “Token ID 42 is owned by wallet 0x123”. No quantities are at play here. If a single wallet owns different tokens in the same contract, each record is stored separately:

Token ID 42 is owned by wallet 0x123
Token ID 69 is owned by wallet 0x123
etc

ERC-777

Read EIP

This standard defines a new way to interact with a token contract while remaining backward compatible with ERC-20.

It defines advanced features to interact with tokens. Namely, operators to send tokens on behalf of another address — contract or regular account — and send/receive hooks to offer token holders more control over their tokens.

So it’s basically a shitcoin on steroids. I have to admit, I don’t have much experience with this standard, but it does look interesting. Again, I encourage you to read the original EIP, it is quite well written and an interesting read.

ERC-1155

Read EIP

Now this standard is the most advanced and it builds on the experience of the previous standards. While ERC-20 and ERC-721 requires deployment of separate contracts per token type, ERC-1155 is a Multi Token standard, that allows mixing fungible and non-fungible tokens in the same contract, with their own supplies, limits, and metadata.

Tokens still have their own unique IDs as with ERC-721, however now the ownership information also includes the number of particular token owned. The ownership information is stored as a multi dimensional map of Token ID → Wallet Address → Number owned. So ownership data is stored in such a manner:

Token ID 42 is owned by:
- Wallet 0x123 owns 2 tokens
- Wallet 0xABC owns 5 tokens
Token ID 69 is owned by:
- Wallet 0x123 owns 1 token
- Walled 0x999 owns 42 tokens

As you can see, this is a merge between ERC-20 and ERC-721 concepts as it includes non-fungibility (through unique token IDs) as well as fungibility through ownership quantities.

Operator Approvals

An owner of a token may allow other addresses (wallets or contracts) to operate their tokens in that particular smart contract. In that case, the 3rd party is called an operator, and the act of allowing an operator is called an approval. This might be a bit different between the standards, but I want you to get the general gist of it.

The operator has full reign over the tokens. This means that if you have approved an operator for your tokens, they are free to transfer all of your tokens from that smart contract to anyone. Usually when placing a token for sale on a marketplace, it asks you to grant approval to that market contract.

This is basically the same as giving your house keys to your local Tesco manager, and trusting that they will only take one Gorilla figurine from your shelf. They might be trustworthy, but don’t be surprised if one day all your actions figures are gone. It might not even be the manager themselves, they might get robbed and your key gets stolen from them.

Some more advanced contracts may implement their own more sophisticated approval systems, but those are out of scope of this article.

OpenZeppelin

A funny thing is that you don’t even need to develop any of this yourself. There’s a company that has developed the implementation of the standards described above. Want your own shitcoin? It’s as easy as opening their Contract Wizard and selecting the features that you want.

A lot of the meme coins don’t even have their own code in them. This is a valid coin contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MemeCoin is ERC20 {
    constructor() ERC20("MemeCoin", "SHT") {
        _mint(msg.sender, 42000 * 10 ** decimals());
    }
}

All it does is assigns a limited number of coins to the contract deployer address. Deployer can then build the hype around that coin and sell on a marketplace.

Blockchain Scanners

For the sake of completeness I also need to mention blockchain scanners. As you already know, all transactions on blockchain are public and transparent. For that reason, most of the blockchains have public scanners, which are just websites that show transactions in a convenient way. Ethereum has Etherscan, and Polygon has Polygonscan. Any transfers, purchases, method calls, and contract deployments you make will appear in those scanners for everyone to see and inspect. Whether this is good or bad, I’ll leave it to your own consideration.

Outro

Thank you for taking the time to read through this article.

There are a lot of misconceptions about the blockchain, NFTs, and coins, and there’s no shortage of people willing to take advantage of the uninformed. I hope this article has given you at least some technical understanding on what the hype is all about.

If you know someone who might benefit from this knowledge, please share this article with them, so that the working principle is demystified.

If you’ve enjoyed the article, please like it, so that I know it was interesting / useful. Discuss any issues in the comments. And maybe consider following me here on DEV. I won’t be focusing on crypto topics, but I might put out an article about it once in a while.

And with all that said – have a great rest of your day.

Fixing Your Backend Git Strategy

Rytis — Tue, 24 Jan 2023 15:16:27 +0000

Have you found your company to be struggling with getting features to production quickly? Is there a big blocker somewhere in your process? It could be that one of the culprits is the way you’re using Git.

This article started as an internal article within MetaHi, therefore it may contain references to problems specific to our company, so don't take it gospel. But in the grand scheme of things, I think that a lot of startups struggle with similar problems, so that’s why I decided to share this writeup, with minimal tweaks.

If it makes you feel better, consider this another shill for a Continuous Integration/Delivery/Deployment process.

What we’re trying to achieve

We want features to appear in production as soon as possible, with the least amount of bugs, and the most value to the user. A great way to achieve this is to practice Continuous Delivery. Here’s some terminology that we should clear up first:

Continuous Integration — builds and tests software after every push. It does not deploy the build.
Continuous Delivery — deploys every change made to the code to a staging environment, and allows for a push to production on demand.
Continuous Deployment — takes it even further, every code changes going through the pipeline will merge into production automatically.

We should strive to achieve Continuous Delivery at least. This means that the code you push should not break the builds, which means that you MUST run the tests and code locally before pushing, and should fix any failing tests immediately.

Here’s a list of requirements. Print it and glue it in front of your eyes:

Features should appear in Prod ASAP
Tasks should not block the release of other tasks
Code in master MUST be production ready (building out of the box, and no failing tests)
Commits in master MUST have proper commit messages
Any API release must be backwards compatible, unless otherwise agreed with Frontend devs

How to achieve it?

Discipline and trunk based development. You need to have discipline to write proper tests for the features you are developing. You need to have discipline to test your code every time before pushing. You need to have discipline to not develop crap, even when you know you are developing throwaway code.

Trunk based development

Trunk based development means that only a single branch is considered the main one. The less time your code spends detached from the main branch – the better. When you are striving to stay on the main branch you will be making smaller commits, thus ensuring that the changes you make are less risky and can be rolled back easily. It will also be easier to integrate with your colleagues, because there will be less merge conflicts. I’m not advocating against feature branches, those are still ok in some cases, but they should not be living for more than a couple of days.

What about the QA step and dev? Nothing in the strategy above conflicts with Dev or QA. You are still free to independently tag your commits with dev tag, so that it gets built into the dev environment. And QA can work either in dev environment, or directly in production. But how do we ensure that users don’t see untested features in production? And the answer to that is feature flags.

Feature flags

Feature flags allow teams to modify system behavior without changing code. You can read an in-depth article about feature flags on Martin Fowler’s website. In practice it means that for any feature or behavior change you want to hide from the user, you should make a config variable. And then taking that config variable into account is as easy as writing an if statement.

However, not every new feature warrants a feature flag. If you are developing some new endpoints that are not going to have frontend attached for a while, there’s no need to make a feature flag, because end users will not be able to reach it by normal means anyway.

A real example of where you would use a feature toggle in the config: let’s say there’s existing code for filtering a list, but it’s not good code. You want to develop something more robust, while the crappy code still remains working. The first commit you would make to master, would be config param something along the lines of use-new-filtering. Nothing has changed and this should be safe to deploy to production. You can then make an if statement in your controller to take this configuration param into account and call an appropriate service (either OldFilteringService or NewFilteringService). And then you are free to actually continue developing your new filtering functionality, continually deploy to prod, and all while still keeping the old code working. Dev environment can have use-new-filtering=true, and QA can keep testing it while you are working, and production environment can have use-new-filtering=false in order to use the old and approved code. Once the code is ready and tested, it’s just a matter of flipping the flag in production to make use of the new code.

Versioned endpoints

Talking about endpoints – they can actually act as a method of feature flagging themselves. If you have an endpoint that has been running on production for a while and you want to fundamentally change it (ie introduce breaking changes), one way to handle that is to create versioned endpoints. Frontend can still use the old /do/something endpoint for the time being, and you can actively be developing /v2/do/something without breaking the first one. When the endpoint is ready, frontend will just switch the URL, and it should be good to go. When old endpoint is no longer actively in use and everyone has confirmed that the new endpoint works correctly, you should take some to remove the older endpoint so that it doesn’t clutter the codebase and confuse other devs.

Versioned endpoints supports our goal of having our code backwards compatible, so that existing features and frontend doesn’t break.

Branching

Let’s get back to trunk based development a bit. As mentioned previously, trunk based development does not forbid you from actually using branches. I would even encourage using them, for more isolation of your changes, and nicer looking diffs when merging. However your branches should live for as short time as possible. We’re talking hours here, or couple of days at maximum.

In practice – all your feature branches should be branched off of master branch. Since there’s a rule that master must always be production ready and work out of the box, it is the safest place to base your code off of.

When the feature is done, it should be merged back to master. Doing it through a PR, or a simple merge is entirely up to you, just make sure it ends up back in master when it’s ready and not breaking.

Branch naming

And let’s for a moment talk about branch naming. Branch names should be as short as necessary, while still communicating their intention as precisely as possible. Prefixes, such as feat/, bugfix/, chore/, and similar are just noise, and let me tell you why.

I would argue that any bug fix should be merged as soon as possible. This means that the branch will live for a couple of hours tops. Since you are writing tests (you are writing tests, yes?), you will write a test to specifically test for the buggy condition. Your test will fail at first, and you will develop a fix in a couple of hours. When your test passes, you know that you have fixed the bug, you are free to merge. But wait, this is most likely a single commit, therefore it doesn’t need its own branch and can be done directly on master. You don’t need to wait for QA to test this, because you have already verified that you’ve fixed the bug by running the tests.

Now let’s talk about chores. What is a chore? Cleaning your room is chore. Taking out the trash is a chore. One would argue that refactoring code is also a chore. But why the hell are you refactoring code just for the sake of it, as a separate task? Code refactoring should be done as a preparation of developing a particular feature that brings value. Refactoring is a part of a feature or a bugfix, and not a separate task on its own. Therefore in reality you won’t see or create branches prefixed with chore/. If anything, your refactoring commits will go inside your feature branch.

This leaves us with feat/ or feature/. Since we have already established, that bugfix branches will either live for a couple of hours or be done on master directly, and there’s no such thing as a standalone chore, then every branch will be some sort of a feature branch. If every branch is a feature branch, why prefix it at all?

Finally we’re left with ticket number prefixes, such as PRJ-123. I don’t have a strong opinion on those, as I can see their value for quick reference. But that’s only valid for a case where there will be multiple people checking the branch (like in PR for example). But you could also just add the ticket number to a PR title, and that would work just as good, if not even better.

One thing that I have a big problem with is NO-JIRA prefixes. What value does this prefix bring? If there’s no ticket for a task, it’s either a quick fix and will either be done on master directly OR the task is too big, and a ticket needs to be created anyway.

Shared dev

In rare instances, it could happen that multiple features can’t be merged to master, but still need to be tested on dev environment. For example you are working on task A and your colleague is working on task B at the same time. You are both working on your own feature branches, but yet you still want both features on dev at the same time.

Enter the shared-dev branch. This of course requires clear communication between the team members, but what doesn’t? How you name the branch doesn’t matter at all, as long as people are aware of what’s going on. This shared-dev branch should be branched off of master, and then your branches should be merged into it. After the branches are merged, the shared-dev branch is tagged with dev tag, so that it builds and deploys into dev environment. When changes are made on a feature branch, feature branch again gets merged into shared-dev and tagged with dev tag.

As soon any feature branch appears in master (read - is ready for release), the shared-dev MUST be deleted to avoid confusion.

Deleting branches

Talking about deletion. For the love of whoever is your god – delete those old branches. If your feature is merged and deployed, there’s no need to keep that old branch and watch as it falls behind hundreds of commits. You can always create a new branch if you need to.

Commits

You should strive to separate your commits into standalone units of valuable code. Think of it this way – if you need to include and word into your commit message, maybe you’re actually committing too much (ex. Add this AND change that).

Commit messages should be human readable, and have the most important information upfront. Since we’re not using any automation tools (if we start using them, we will reevaluate this), we shouldn’t prefer cryptic tags fix(), feat() and similar (comes from Conventional Commits, including link just for curiosity) at the start of the message. The ticket reference (PRJ-123) should go at the end of the message, because it does not communicate immediate information, without having to reference a 3rd party system.

You should definitely read this in depth article about good Git commit messages.

Imagine that after doing a commit, you would go on Slack and describe the changes to your colleagues in a message. A great place for that message is actually the commit message body. Add a blank line below your commit message and explain why you made the change, and possibly how to use it.

A good commit message should look something like this (completely fictional):

Add metadata to asset details. PRJ-123

Asset metadata was missing from asset detail page. Metadata is 
needed for OpenSea and similar 3rd party systems in order to
display the asset correctly. Metadata should now be included in
the asset details endpoint.

Pull Requests

Pull requests are inefficient, change my mind. First, they stop code from appearing in master which we have already established is a bad practice in itself. Second, in order to properly conduct a code review (and I mean properly, not only check the indentation), you probably need to spend just as much time as writing the original code. Therefore a better practice is pair programming – in the end just as much time is spent by a couple of people as with PRs, but the added benefit is that the feedback is instant and can instantly be addressed.

I’m not advocating against pull requests, if you want someone to quickly go over your code just to double check for those low hanging fruits, but I’m also saying you don’t need to ask someone’s permission to do your job.

On a side note, a senior developer’s approval on a PR does not mean that suddenly you’re off the hook and anything bad that happens with your code is now the responsibility of the approver. It is your responsibility as a professional to make sure that the code meets business requirements and is factored to the best of your abilities.

What doesn’t work

Throughout many years, me personally, and the industry as a whole has learned new things. We’ve also learned what doesn’t work, or doesn’t work in our context at least.

GitFlow

One of such things is GitFlow. GitFlow is a branching model created by Vincent Driessen more than a decade ago. The author himself, has stated that this is an outdated model, and should not be used in continuous delivery environment. Original article here.

Standalone `dev` branch

Some of you may remember times when dev was a separate branch. A big problem with that is the same as with any other long lived branch – it tends to quickly diverge from master. Especially if you have many features that are tested on dev, but never end up in production. There comes a point where the whole dev branch needs to be deleted and then branched off of master again. And that comes with its own sets of pain.

Outro

So this was my heavily opinionated article about how Git should be used. If you disagree, please voice your discontent in the comments to boost the engagement. But in all seriousness, let's discuss the process that you find works in your context – I love learning how to improve the efficiency.

How to Bring Back Old IntelliJ Look (somewhat)

Rytis — Thu, 05 Jan 2023 13:13:51 +0000

There's also a video version of this same article

Intro Rant

Feel free to skip this and go straight to the practical tips.

All good things come to an end, and it looks like the time has also come for IntelliJ’s old design. While it makes me sad to see JetBrains fall for the VSCodification¹ trend, I do realize that it is inevitable, and there will come a moment when this abomination is forced upon us, and there’s not much that I can do about it. So I decided to bite the bullet and switch to the new design to make the transition more gradual - new year, new look, amirite?

After switching, I am immediately greeted by trendy excessive padding around every element - something that is more suited for a touch interface rather than a productive work tool, and a contrasty color theme that looks like a direct knockoff of VSCode. I even whipped out a color meter to check - colors are not the same, but pretty damn close (VSCode background is 30,30,30 and new IntelliJ’s is 30,31,34, in case you were wondering).

Anyway, I decided to give it a shot for a day despite my bitterness, and I very quickly realized that I can barely even fit two classes side by side due to that gosh darn padding. And the color contrast was starting to strain my eyes. So I decided to check what settings I can change to actually make it look more like good old days.

Change Back To Dracula

The first thing that has the most impact is the actual IntelliJ theme that you are running. And I didn’t know this, but it seems that a lot of padding is actually baked into the theme itself, so changing back to good old Dracula theme already brings back a lot of information density:

While you’re at it, you can also change back to .AppleSystemUIFont instead of their new Inter font. I haven’t dove deep into why the new font is better (it very well might be), but I really hate when UIs use non-default fonts, it just falls out of context from the whole OS.

Disable Auto Opening of Files

Another thing that I’ve noticed with the new design is that they’ve enabled file opening by default when you click on the file tree. If I want to open a file, I double click on it. Opening on a single click is annoying, distracting, and might introduce lag depending on the system.

Apparently this is called “Preview Tab” and to disable it, you have to click on the kebab menu (three vertical dots) and uncheck Enable Preview Tab. You will now be able to navigate the file tree like the good old days.

Also, depending on your taste, you might want to check Show tree indent guides and/or Use smaller indents in trees in Appearance preferences. I personally don’t like small indents (two spaces as indent must die altogether, but that’s another topic), but indent guides are definitely nice.

Breakpoints

Another change they’ve made is that breakpoints now go over line numbers. This might save a bit of space depending on where you place a breakpoint, but that can also be annoying. You can disable this behavior by right clicking on the gutter and unchecking Breakpoints over line numbers. I don’t yet have a strong opinion about this one, but I’m experimenting with both.

A bit annoying addition is the breakpoint preview on mouse over. As far as I know that can’t be disabled unfortunately.

Talking about right click, I use it a lot on the gutter to enable Git Blame, and oh god did they messed that up. Depending on where you right click it will bring a different context menu. And most annoyingly, if you right click the arrow, it will toggle the fold instead of showing the context menu. This has got me so many times already. Hopefully they will fix this soon.

Navbar / breadcrumbs

They have also changed the location of the Navbar to be in the status bar. If you want to change it back to where you’re used to, you can go to View > Appearance > Navigation Bar > Top.

I personally think it looks weird at the top with the current design, so I will make myself get used to it at the bottom.

Git Branch View

The Git Branch view has been removed from the bottom right status bar and everything Git related has been moved to the top left. You can however still enable the old location of Git Branch by going to View > Appearance > Status Bar Widgets > Git Branch. Now you will be able to control Git from both corners of the screen.

Fat Side Icons

Unfortunately, I haven’t found a way to bring back good old slim text instead of the fat side icons. Those icons do take a lot of useful space, without actually providing more information compared to text. Again, it’s not a touch interface, we don’t need fat buttons, mouse is a precision device, and I don’t think people had trouble clicking it before. But trends are trends, the pendulum will swing to the other side in about 10 years or so.

Run Widget

I haven’t found a way to customize that either. It seems that you can right click choose Customize Toolbar, but nothing you do there makes a difference. I did read that they will tone down the distracting color of the run widget in the next version. With that said, I’m not a fan of the new run widget either, especially stop button disappearing when nothing is running. But I’ll get used to it eventually.

Outro

With these steps I was able to somewhat bring back the old look of IntelliJ and get rid of the annoying padding around everything. When a colleague initially showed me the new theme, I was sad and frustrated that I will soon have to face VSCode looking IntelliJ every day, but after doing a bit tweaking, I can see that the future is not as bleak as initially thought. This brings a bit of peace to my mind, and if you’re anything like me, hopefully this will also bring a little bit of peace to you too.

Please share your frustrations in the comments, so that we can be frustrated together 🙂. And if you find any tips on making the new design a bit better, then definitely share that in the comments. I will update this post with more tips when they're found. But with that said, thank you for reading my salty rant with a bit of practical information sprinkled in.

For a list of changes, you can check the Official Post from JetBrains

VSCodification trend is when every IDE wants to be like VSCode. Well at least IntelliJ is not an Electron app… yet ↩

Should routing go before security?

Rytis — Tue, 12 Jan 2021 10:12:10 +0000

Recently I've got into an argument with a colleague in regards to what HTTP status to return.

The way our API works right now: you need to be authenticated to call any route except the ones which are explicitly configured as public. This means that if you call any endpoint (doesn't matter if it exists or not) without a token, you will get a 401 response. If you call a non-existing endpoint with a valid token, only then it returns 404.

My colleague says that it should be the other way around and we should first check if the route exists and only then validate the token.

What's your opinion on this issue? I've seen it done both ways and I don't have a problem with either approach, but I am leaning more towards returning 401 before 404, because unauthenticated calls shouldn't reveal whether endpoint exists or not.

How I Fixed IntelliJ Build Problems After MacOS Update

Rytis — Wed, 27 Nov 2019 10:25:48 +0000

Backstory

Feel free to skip this section if you don't care for a short story. There's a tl;dr; at the bottom.

I came back to work after my vacation, fired up IntelliJ, punched in a few lines of code, compiled my Spring project, and... nothing changed. No errors, everything compiled and ran perfectly.

At first I thought that this was cache related, even though I was doing http requests through Postman. So I entered a few logging lines on startup and tried again just to find that they too were not shown.

I then tried to do a Build > Rebuild Project and got an error saying something along the lines of Could not get UNIX mode on /ProjectDir/build/File.class. File does not exist. It was then that I realized that there was something wrong with build folder access.

How I Solved It

Since build folder is generated automatically I simply deleted it for the offending submodule. When I tried to rebuild the project, another submodule that previously compiled now showed different errors.

I remembered that during my vacation I upgraded MacOS to the newest version and the update probably messed with the user or permissions or something along those lines.

So I just deleted build and out folders for all the submodules, rebuilt the project successfully and voila - all was good and I started seeing the changes I've made.

Moral of the story - delete generated folders after OS upgrade, just in case.

TL;DR;

After upgrading to the latest MacOS, new changes to my Java code didn't make it into compiled version. I fixed it by deleting generated build and out folders for every submodule.

Setting up Intellij to close previously running build

Rytis — Thu, 07 Nov 2019 16:28:30 +0000

Hello there, I've been struggling with this problem for 2 days now and I am completely lost.

So I've upgraded to most recent IntelliJ Idea and it turns out that they've changed the default "Build and Run" option to be Gradle (under Preferences > Build, Execution, Deployment > Build Tools > Gradle. Which is totally fine by me, if not that annoying feature where it now starts up as many instances of the program as you click run.

It used to be like this:

I punch in a few lines of code
Ctrl + R to build and run (under Mac, Windows has another shortcut)
Old instance of my program terminates
New instance of my program launches
Go to step 1 and repeat ad infinitum

And now it's like this

Ctrl + R to build and run
Gradle builds the program
Program starts up, but the build keeps spinning

Build only stops when I close the program manually. If I press Ctrl + R again, a new build launches with a new instance of the program and I find myself running 15 instances of slightly different programs more times than not.

So ideally I would like the build to be marked as complete when the actual build finishes and not when I close program. Also I would like to run only one instance of the program at a time and if I build a new one, I want old one to close down.

By the way, Parallel run is not checked under run configurations.

Another Problem

Now I could just change "Build and Run" option to be IntelliJ and be happy with the old functionality that I liked before. The problem is - when I do this it suddenly can't find any of my resources. The resource folder is marked as resource root. I can also find my resources moved to build/resources/main/. But getClass().getResource("/asd.fxml") always returns null.

I also cannot change anything in File > Project Structure as applying any changes starts throwing all kinds of errors, and the structure is managed through Gradle anyway.

I'll buy a pizza for anyone who helps me with either of the problems.

Hiring the Right People

Rytis — Mon, 19 Aug 2019 20:33:18 +0000

Hey, community! Recently I've been invited to give a talk at a local conference about the early stages of a startup and I chose to speak about my take on hiring the right people. I thought that it would be beneficial to share my speech with y'all.

It may not be directly development related, but I'm speaking mostly from the perspective of a CTO and long time team lead to a crowd of people interested in starting their own companies.

Please share your thoughts and insights in the comments!

Intro

So, you have a killer idea that has been circling around in your head for quite some time? You finally decide to take that leap of faith and start up a company. A startup! Maybe you’ve been working on an idea alone and now you’re looking to expand? The only problem is – what kind of people do you need? Can’t you just get a bunch of programming students to work their magic and then a bunch of marketing students to push your product on the cheap? Well let’s find out, shall we?

The Most Important Person in Your Company is You!

Now that sounds a bit egocentric, doesn’t it? Well hear me out on this one. When a company is young, the first people you hire are going to be the most important ones. They will shape the culture and work ethic. And while you’re alone, you are the one shaping those things.

You must also take good hard look at yourself and figure out your strengths, but most importantly your weaknesses, which brings us to the next point.

Find a Co-founder Who Complements Your Own Skill Set

A great co-founder is a must if you want to keep your sanity. A co-founder should fill in the gaps in the skills that you lack. Maybe you’re a good programmer, but not such a good salesman? Then the co-founder should fill in that gap and be a great salesman. In the ideal world, co-founder skills should hardly overlap yours. It’s a great way to let everyone do what they do best and avoid conflicts when someone has a different approach to the same problem.

At my current company we have a great dynamic, where my colleague knows a lot about the Danish tax system, but nothing about programming, and I am just the opposite – I know programming and system architecture, but nothing about the Danish tax. Working like this, we just need to sync up once a week and continue doing what we do best!

With that said, there will come a time when you need to bring in more talent to the team.

Hire for a Team Fit, not for Skills

Time and time again, I have seen startups hire a candidate that looked great on paper, but once they joined, they started struggling to fit in. And when people are struggling to fit in, their productivity suffers. They will want to spend less time around other people in the office. They will struggle with communication. They won’t be sincere with their feedback.

A great example is the experience of a company I used to work for. The team dynamic in the company was great! Everyone considered their colleagues a family, organized events together, spent time outside work as friends, and so on. And then we hired a new developer. As his skill set was all right, and he had considerable experience, we didn’t dig much deeper and after a few interviews we invited him to join. After a few weeks, the mismatch was starting to become apparent – he didn’t like any of the same things as anyone else. Although he was extroverted, it didn’t interest him to attend any of the team-building events. And even though everyone in the team was trying hard to find some common ground with the fellow, he just didn’t seem to click. The worst of it all was he was working on a module alone and left immediately after he got offered a bit more money at another company.

The damage was 4 months of above average salary for the developer, plus 3 months to find a new developer, plus rewriting the module he was working on from scratch since it didn’t do anything it was supposed to do. And since the budget runway was 12 months, it was a pretty significant cost for that startup.

Remember, skills can almost always be learned, team fit cannot. So, hire slow, hire carefully. Allow a trial period for potential candidates, take them out for a beer, go to a concert with them. A good colleague is the one you don’t hate seeing outside work! But…

Don’t Hire Your Friends

You may think that it’s a good idea, you know your friends, they’re great people. But once you add salary into the mix and change the rules from being their friend to becoming their boss, it tends to get messy. Friends and money don’t mix. They may start slacking off, just because they know you as a friend. Then you might want to push them, but it comes off as harsh and they feel attacked. And in the end, everyone’s mad and you just lost a co-worker AND a friend.

Don’t get me wrong, some people can indeed separate their work life and social life, but it’s best not to take that risk.
I say – let them become your colleagues first, and your friends afterwards. This way you won’t mess up the chain of command.

Early Team Culture is Super Important

Now let’s take a step back and discuss your team culture. The first people you hire are the most important ones. As I’ve mentioned at the beginning – they will shape the work ethic, the way people interact, the way they communicate. It is highly unlikely that you will be hiring a lot of new people at the same time, so the new people are going to be a minority. They will have to adapt to the existing culture and are most likely to start mimicking the way everyone else is behaving. It’s a primal instinct. So once the tone is set, it may be very difficult to change afterwards. And changing it may even result in your key people leaving, because you just changed the way they had been doing things since the beginning.

Don’t Waste Time or Money on Subpar Talent

You have to hire great people if you want to have a great product. But great people don’t come cheap. It may be tempting to bring in a student because, hey, they’re cheap and they still get the job done. But those savings are going to quickly bite you in the butt in the form of a technical debt. The structure may be all messed up and the project will reach an unscalable state where adding a new feature takes so long that it’s best not to start at all. And let me tell you – rewriting the project costs at least 3 times more than you ever anticipated. So, it is best to just get one really smart person for a price of two mediocre ones, everyone will thank you later.

Here’s another example from a company I used work for. The company used to sell a SaaS product and hired only student interns as salespeople. Since most of the students were on Erasmus, they would leave in half a year. This was fine for cold calling when the product was just a single small module. But once it got bigger, it took a lot time to train those students about that product. And by the time they knew everything about the product they were selling; it was time for them to leave. Fortunately, this was noticed by the board and 15 sales interns were replaced by a few skilled full-time salespeople.

It Doesn’t Always Have to Be About the Money

When you’re running a startup, money is always very limited. You may not have enough money for the talent that you want. But it doesn’t always have to be about the money. Top-tier people can always get a well-paid position, so money is mostly not a priority for them anymore. They are usually looking for an interesting project with highly motivated people with whom they can collaborate. So, think what your startup can offer your employees beside money. And no, a foosball table is not that thing. In my career as a lead developer I have deduced that freedom is what works. I tend to allow people as much freedom as possible – want to work from home? That’s fine as long as the communication is good, and the job gets done. Don’t feel like working today? Take a day off – it’s much more efficient to rest for a while than to force yourself to squeeze that last drop of energy.

Another thing you can offer, and I know I have mentioned it a lot before, is a great team. I would always choose a great team versus more money in a bad team.

It’s Cheaper to Retain Your Current Staff

Since money at startups is in short supply, employee turnover can be deadly. An employee leaving does not only mean compensating them for their unused vacation days, paying a recruiter to find a new candidate, and training them. You should also factor in the cost of lost knowhow. Maybe that girl who just left had been working on something alone and now someone else has to dedicate their time to understand her work. Moreover, a leaving team member can cause a domino effect and other members may follow in their footsteps, which I’ve seen time and time again. And if you’re hiring in a market with a very scarce supply of talent, such as programmers, it means there won’t be any freely available employees. Which then, in turn, means that you will have to headhunt people from other companies, which will again hike up your costs.

Therefore, it is much cheaper to retain people that are already working for you. Ask for their honest opinion on the current state of the company monthly. And if they don’t feel like they’re valued enough, it will always be cheaper and more beneficial in the long run to give them a small pay bump rather than going through the leave-recruit-train process over and over again.

The Most Suitable Person May Already Be in Your Team

It is always the easiest not to hire new people at all. This again boils down to communication and knowing your colleagues very well. Talk with your existing employees about what excites and interests them. You may find that this one extroverted HR rep is actually a pretty good salesman. Or this introverted developer is actually very good with social media. And introducing changes into someone’s day to day work may provide them with that very well needed break from the rut. You may be surprised at what hidden talents you may find.

Fire Early, Fire Fast

However, there will come a time when someone you hire will just not work out. It may be that they’re just not bonding with the rest of the team. Or it may be that you find out that their skills are lacking after all. In that case, it is much more beneficial to just let them go. Do it fast, because the longer they spend working on something that will have to be transferred to another employee, the more it will cost YOU.

Outsource Everything Else

With all that said, maybe you don’t even need a full-time person to do some of the work. I have found that outsourcing some tedious or one-off jobs may seem to cost more upfront, but it may actually lead to better results if you’re hiring a really professional agency or person. Always try to evaluate whether the task at hand must be handled by you or your team or is it something an outsider could easily do. Outsourcing can alleviate the stress from yourself and your colleagues. Try it, you may not regret it.

Lead by Example

Finally, I’d like to give a few important examples on being a bad founder after you’ve already assembled a team. A company that I was advising had a great and motivated team that liked getting things done. They also had a CEO who was so overworked that he was always late for meetings and sometimes even forgot them outright. Over time, I saw that team transform from punctual go getters to just not caring at all. Their argument was: if the CEO doesn’t care much about their time, neither should they care about the company’s time. By the time I stopped advising the company, their meetings got delayed on average by about 30 minutes, just because they were waiting for people who didn’t care to show up.
And same with deadlines. The CEO would promise to deliver the specification on a certain day, and then he would just forget about it, so the team also started skipping deadlines because they saw that it was just not important for the company’s brass.

A Good Founder is a Good Router

Talking about that same company. Their CEO used to want to do everything himself – bookkeeping, taxes, sales, product ownership, wireframes, he even suggested how the database should be structured. No wonder he was overworked, late and skipping meetings. Therein lies the problem – don’t try to do everything yourself. When people bring up a problem, redirect them to someone who can handle that problem. Empower people to make their own decisions and hold them accountable for them.

Make yourself available and don’t do the work that someone else can do. For example, you don’t have to do your own taxes – hire a tax advisor once a year or so. Your employees will thank you for having you available when they need your input.

Conclusion

Here I have told you about my take on hiring the right people. Please note that this is tailored for small startup teams and may not work at a larger scale (but you don’t want it to). Always use strategies that fit your current state of the company and never try to apply a 100 people strategy to a 5-person team. Don’t follow everything by the book, chances are your situation is different.

To sum up:

The most important person in your company is YOU
Find a co-founder who compliments your own skill set
Hire for a team fit, not for skills
Don’t hire your friends
Early team culture is super important
Don’t waste time or money on subpar talent
It doesn’t always have to be about the money
It’s cheaper to retain your current staff
The most suitable person may already be in your team
Fire early, fire fast
Outsource everything else
Lead by example
A good founder is a good router

Thank you for taking your time to read this long text.

DEV Community: Rytis

NFTs, Blockchains, and Standards Explained without BS

What is a Token / NFT

Technical Workings of Smart Contracts

Views vs Transactions

Smart contracts in terms of crypto tokens

A word on immutability

Contract migrations

Differences between blockchains

Token Standards

ERC-20

ERC-721

ERC-777

ERC-1155

Operator Approvals

OpenZeppelin

Blockchain Scanners

Outro

Fixing Your Backend Git Strategy

What we’re trying to achieve

How to achieve it?

Trunk based development

Feature flags

Versioned endpoints

Branching

Branch naming

Shared dev

Deleting branches

Commits

Pull Requests

What doesn’t work

GitFlow

Standalone dev branch

Outro

Further Reading

How to Bring Back Old IntelliJ Look (somewhat)

Intro Rant

Change Back To Dracula

Disable Auto Opening of Files

Breakpoints

Navbar / breadcrumbs

Git Branch View

Fat Side Icons

Run Widget

Outro

Should routing go before security?

How I Fixed IntelliJ Build Problems After MacOS Update

Backstory

How I Solved It

TL;DR;

Setting up Intellij to close previously running build

Another Problem

Hiring the Right People

Intro

The Most Important Person in Your Company is You!

Find a Co-founder Who Complements Your Own Skill Set

Hire for a Team Fit, not for Skills

Don’t Hire Your Friends

Early Team Culture is Super Important

Don’t Waste Time or Money on Subpar Talent

It Doesn’t Always Have to Be About the Money

It’s Cheaper to Retain Your Current Staff

The Most Suitable Person May Already Be in Your Team

Fire Early, Fire Fast

Outsource Everything Else

Lead by Example

A Good Founder is a Good Router

Conclusion

Standalone `dev` branch