NEWS & ARTICLES

    #technology
    #frontend
    #UX/UI
    #product managing
    #entrepreneurship
    #leadership
    #start-up
    #backend
    #NodeJs
    #Java
    #OpenAPI

Jiratech named 2020 Top B2B Companies in Romania by Clutch

September is about learning and new beginnings.

And this year, 2020, Clutch recognized Jiratech as a top software development company from Romania.

Clutch is a platform focused on exploring top services and solutions across industries to find the right resource for your business.

Inc Magazine has also recognized Clutch as one of the 500 fastest-growing companies in the United States, and more than half a million buyers and sellers use this platform each month.

It has over 200.000 agencies and over 500 categories, so we are humbled by and grateful for the news.

"I want to thank the entire team for their involvement, we are in awe for the recognition, it is a well-deserved win reflected by both our commitment for empowering innovation and our incredible clients' feedback," said Radu Jinga, founder and Managing Partner of Jiratech.

 

Read more: https://clutch.co/press-releases/recognizes-top-b2b-companies-romania-2020

Shape OneShape TwoShape ThreeShape FourShape Five

OpenSource OpenAPI Boilerplates - NodeJS & Java

We, at Jiratech, strive to empower innovation and build customer-driven innovative products with embedded immune system*.

We also have a program, Jiratech Foundation, in which we give back to the community and engage in social projects ( more on this, here: https://jiratech.com/company/foundation ).

 

On this note, those are the boilerplates that we created and we use regularly:

 

1) Java Spring Boilerplate: dockerized, API-first 3 layer architecture with PostgreSQL and Minio connectors.

Link: https://github.com/Jiratech/boilerplates-java

 

2) NodeJS Boilerplate: ExpressJs-based, typescript-adapted, 3 layer architecture with PostgreSQL connector.

Link: https://github.com/Jiratech/boilerplates-express-typescript-openapi

 

Those boilerplates have a unique characteristic - full integration with OpenApi v3 ( documentation here: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md). We wrote a tutorial on integration with ReactJS here.

 

Those boilerplates use a single, descriptive JSON of the APIs and DTO ( for typescript, interfaces) that map and enforce the request and response and also generate the APIs ( Java) / handle the route components ( NodeJs).

You can find this schema here: https://github.com/Jiratech/boilerplates-openapi-schema

 

I hope this helps you speed up reliable development as it did for us!

If you want to contribute or comment, we welcome any feedback

Coming soon: ReactJS boilerplate and React-Native boilerplate with TypeScript and OpenApi.

Shape OneShape TwoShape ThreeShape FourShape Five

Integrate OpenApi specification using openapi-generator to a ReactJs project with Typescript and Axios

As a frontend engineer, I am always looking for ways to be more effective and efficient. So the main scope is to be more productive in building the architecture of the application and get rid of the small implementations that consume time. I have spent endless hours changing the API call layer, including the DTO’s. Alongside my team, we found a way to have a common ground for frontend and backend engineers to communicate more easily and be more productive. In this article I want to make you work smarter :

- by generating functions for api calls and generating interfaces of your main objects in the application;

- by having more transparency when there is a change in the openapi specification of your project

 

OpenApi

OpenApi specification defines a programming language-agnostic interface description for REST APIs. Read more OpeApi Specification

 

Goals

Given an OpenApi specification (JSON or YAML file), we would like to generate the following:

- interfaces of the DTO’s;

- functions that can be used for calling APi’s;

This generated data will bring all the information you need, not just for what routes are exposed, but also which data types they use to communicate (request/response parameters).

 

How to accomplish these goals?

Before starting you will need a JSON or YAML file. You can read more about the format of this file on the following link OpenApi Specification Format.

This is a simple example of how a JSON file will look like: Exemple OpenApi Specification

 

Using this example we must take the following steps:

1. Choose a code generation tool.

For the frontend application I use OpenApi Generator.

Pros: It is straightforward and you don’t need further configuration in the application. You just need to modify the options of the command line used for generating the code (OpenApi Generator Typescript-Axios).

Cons: You need to have Java installed on your machine/docker

Also there are also other libraries that you can use:

- OpenAPi client (OpenAPi Client);

- Sw2dts (Sw2dts);

2. Define the command line that will be used to generate the code.

I use the following command line:

openapi-generator generate -i [*json file path*] -g [* client generator*] -o [*folder path where you want to generate the code*]

Now you can add this in your package.json scripts category.

I use ‘typescript-axios’ as *client generator*. I use axios because it is a popular library for http calls and I use it in most of my React projects.

I prefer to add the following option ‘ — model-name-prefix I’, because this will add to the name of Interfaces the prefix ‘I’.

Why? Maybe you need to define classes that implement these interfaces for setting some default values of the fields. This is a naming convention that will help you, especially when you will be importing both of them into other files.

 

How to use the generated code in your application?

One of the goals was to use generated functions for making api calls. To achieve this goal we need to import the class UserApi from the generated folder and instantiate it: const userApi = new UserApi(). The instance of the class contains all the functions that you need for making api calls to the server.

But now some questions arise:

- How do we write the config for the api call (ex: headers, timeout, baseUrl)?

- How do we add interceptors for the calls (request/response interceptors)?

Well.. the answer is quite simple. You can create an axios instance: axiosInstance: AxiosInstance = axios.create({…}). At this instance you can add interceptors and other config specifications.

After you configured your axiosInstance you can add it as a parameter when you instantiate the UserAPi:

const userApi = new UserApi(null, BASE_URL, axiosInstance);

Also if you have an api call that needs to have other configuration than the one you set up on the axiosInstance, you can override it by using the class Configuration imported from the autogenerated OpenApi folder:

const userApi = new UserApi(new Configuration({ baseOptions: {…} }), BASE_URL, axiosInstance);

 

Use OpenApi generated code in your sagas.

Because context in javascript is dynamic based, when you try to use a userApi instance for making an api call you will be receiving the following error: ‘this is null’.

const response = yield call(userApi.loginUser, …args); // error

To manage this error you have to provide the context in some way. The call effect supports multiple ways of providing context. You can find them in the official docs Redux Saga Call Context, here is the short version of it:

const response = yield call([userApi, userApi.loginUser], …args);

 

Also you need to be aware of the following:

- Never modify the generated code!

- In order to have application up to date you will need to generate the open api code at every build

- The generated code needs to be specified in the .gitignore file

- The OpenApi specification will be used by different types of applications (mobile, desktop, web, server, etc..) . So be careful when you modify them because you can impact different platforms.

- As a best practice you can keep the .json or .yaml file on a separate git repo. In this way every developer can be aware of the changes.

 

If you are looking for an OpenApi Specification for starting your own computer vision project, here are the standards that we are using for building our own projects:

- DeepVISS-TAG

- DeepVISS-COMMON

- DeepVISS-OPS

Shape OneShape TwoShape ThreeShape FourShape Five

How to start-up your tech

Starting as a software developer in a multinational company my main driver was always improving my skills as a coder, so I was always reticent about the long-lasting meetings, the pain of setting up the environment, and all the time wasted on running and fixing tests with almost no return on investment. During each of those meetings, a thought ran through my mind asking me “Why do we keep losing time, when we could implement this thing?”

 

After I resigned there, I started working on a startup with some friends and the beauty of working there couldn't be compared to my last job. There were no rules, no meetings and no restrictions on the resources that we had. We didn’t need to make a request in order to have access to a repository, wait days to have a program installed or fix tests. We were just a team of four people sharing technical knowledge with one another and working day and night on their idea, using a wall full of sticky notes with features or bugs as a backlog and competing to see who would finish more of them by the end of the day. The only drawback was not having someone with more experience to guide us on the right path, so we started making mistakes, learning from them and correcting them as we were moving along.

 

As our codebase kept growing so was our team, and since every member was working on their little piece, we started losing the bigger picture. We couldn’t know if something done by X could impact something done by Y, and with the burnout being right behind us, we made obvious errors that someone could have foreseen them if he had the chance to review what was written.

 

We realized that we can’t keep working like this for much longer, our backlog beginning to fill up with regressions and technical debt. For the first time, I understood why we had all the meetings and all the restrictions in that company. So, we needed a model just like that to have stability. But we were still a startup. We couldn’t afford to lose precious time in meetings or reviewing what is done. We needed our own workflow. Something that would not add too much overhead to our productivity, but enough to assure us that the production errors will decrease, and we would be able to see an overall picture of how the development is going.

 

The search for tools and services that can help us automate most of that overhead started. As every company out there the best and most obvious start point was Atlassian, since we were already using Bitbucket cloud as our versioning tool. But we didn’t stop here. We added continuous integration and continuous development tools, private docker registry, error monitoring tools, an analytic engine for logs to store, search and view, automatic static analysis of code, static and dynamic security testing services, all of them interconnected with one another, all connected to the same user directory to ease the user management, choosing the opensource solution whenever one that suited our needs existed. We added and configured them with the mindset that if something can be automated, then it should be automated.

 

Since our team is working under a VPN we wanted to have all the tools needed for development in-house, so we installed them on-premise, in our local server. This is the point where things start to fall apart. In no more than two months a blackout fried the server’s motherboard. If it weren't for some backups that we did manually, all the data would have been down the drain, from tasks and documentation to code. But, we still lost all the hours of work installing and configuring those tools.

In order to keep this from happening again the cleanest and viable solution was Docker. Since Atlassian and some other third-party providers don’t support docker, we used images created by the community or we created images to suit our needs. Everything was working, every volume was stored on our network-attached storage, and we could have replicated that on any virtual machine with a simple docker-compose command. But it wasn’t scalable. And if something would have happened to a container, by the time we figure it out is down and what is the problem, it was already too late.

 

To mitigate this issue, the solution at hand was to move everything in Kubernetes. Combined with Rancher, all the tools are scalable, every piece of data is backed-up every day and we get notified about what’s not working and why is not working.

 

By the beginning of 2020, our try to have some order and a prediction in the development process turned into a whole project, deployable and replicate-able with just one click, with self-scalable services that are constantly monitored for flaws and malfunctions. From versioning tools, task managers, error handlers and notifiers, code analysis tools, log monitoring, and ci/cd, all the services that we used are under one manager that works for us as our 24/7 DevOps, providing us with metrics, statistics, and forecasts about the infrastructure.

 

We believed that adding an overhead to the development process will impact performance, but in fact that overhead and the time allocated on building this process, saved us months of refactoring and most importantly our relationships with the clients as if one would have called us to report a problem, our developers were already preparing a fix for that problem, knowing which task, what commit, who added that commit, how was this issue introduced and why it wasn’t caught by the tests.

 

This is the trade that everyone has to make at some point, in order to bring order into chaos, and we found out the hard way that the overhead is unperceivable if you are using them right. We found a balance in our workflow, and we believe that this isn’t done yet. We are in the 3rd iteration and we still think that it can be better, every day improving our system, automating the automation, having the machines work for us and not the other way around, so it would make our life and the life of people to come easier.

 

Shape OneShape TwoShape ThreeShape FourShape Five

An open-source safe net against Covid-19

Nearly 5 hours ago, the government of Singapore finally decided to release the source code of the TraceTogether application that they were using to reduce the spread of COVID-19. This application helps by safely and securely monitoring the distance between every phone that has the app installed and giving you recommendations for self-isolation or even quarantine, based on all the people you encounter in your day-to-day routine.

This is a major development because of their advancements in finding the right parameters and functionalities of such an important and critical solution can now be shared globally. People across the globe can modify the newly open-sourced solution and quickly release and distribute their own version of it, free of charge but with some limitations.

Limitations consist of:

 - having to keep the solution open-sourced, with the same license it was released

 - keep track of any modifications that occur to the code in the eventuality of the Singaporean government asking them to release all modifications as open-source

In my opinion, those limitations are good, keeping the people at bay for eventual add-ons that will jeopardize the user's privacy.

Wich people exactly? Good question,  Apple released the following statement: "To ensure the credibility of health and safety information, Apple is only accepting COVID-19 related apps from recognized entities such as government organizations, health-focused NGOs, companies deeply credentialed in health issues, and medical or educational institutions. Only developers from one of these recognized entities should submit an app related to COVID-19 to the App Store. For more information visit https://developer.apple.com/news/?id=03142020a". That statement will exclude most if not all of the people that can take advantage of the good-will of the Singaporean people and want to help their country in the battle against the spread of Covid-19.

What can you do now?

No matter the country now it is time to put pressure on the people you voted to defend you at any cost. Ask them to bring tech people they trust to the table, and act upon this chance swiftly and without hesitation. Tell them that you need this app because you want a safety net of responsible people around you, people that stayed home when it was required and now they will try to re-enter 'normal' step by step. And the first step is regaining trust in each other.

What WE ( Jiratech, Envisage, DeepVISS ) are going to do now

In the last month, we've pitched this idea to a series of investors, businessmen, founders and public with hopes of gaining enough founding and visibility that will eventually put in motion two separate processes: getting started developing such Romanians and opening our government's or other health-based NGO's doors to release the app under their authority.

Now we are currently documenting the released code, looking for security issues, vulnerabilities and other problems that we may encounter in transforming their solution into a solution that is ready to use by all of our peers. Our public repositories can be found here, for any developer that wants either to use it as their own solution or help us modify it and prepare it for public release in Romania. In order to comply will with all regulations in our country ( GDPR being one of them ), we are currently investigating all of the flows of the data and their protection, to ensure that this app will be 100% compliant at the time of the launch.

Shape OneShape TwoShape ThreeShape FourShape Five

Pariem pe startup-uri cu tehnologie

Jiratech a acumulat experiență livrând cu succes produse software în industrii variate și, contribuind astfel, la dezvoltarea unui număr semnificativ de startup-uri. Acum, compania plusează prin oferirea unei noi alternative pentru fondatorii care au nevoie de un partener tehnic și sunt dispuși să convertească un procentaj din business. 

Această metodă se adresează start-upurilor tech aflate în stadii incipiente, oferindu-le acestora o gamă completă de servicii de dezvoltare pentru produsul lor software. Procesul este numit incubare tehnică și presupune atât asigurarea unui “product life cycle” - de la idee până la lansare, cât și o metodologie dedicată unui produs inovator, pregătit pentru producție și pentru creștere accelerată.

În plus, abordarea presupune implicare la nivel de business prin recomandări de stabilire a direcției, vitezei și costului, pe care antreprenorul să le imprime propriei afaceri.

Pasul care precede orice colaborare cu compania îl reprezintă estimarea efortului total de lansare a produsului - de la analiză și dezvoltare, până la lansare și mentenanță. Pe baza acesteia se conturează modalitățile posibile de parteneriat (“fixed price” sau “time & material”), o serie de milestone-uri, un interval de efort, alegerea tehnologiilor potrivite și componența echipei.

Colaborările demarate cu scopul procesului de incubare tehnică prevăd în plus față de estimare o listă de întrebări menite să facă “o radiografie” a afacerii și să departajeze candidații. Apoi, efortul este co-finanțat de Jiratech cu un discount de până la 30%. Acest pachet se oferă pentru convertirea unei părți din business de până la 20%, în funcție de caracteristicile fiecărui start-up.

 Dacă nu se ajunge la un consens, compania asigură valabilitatea ofertei de colaborare provenită din procesul de estimare descris anterior, în regim standard de dezvoltare software.

Jiratech le propune celor care vor sa dezvolte un produs inovator un pachet ce include asigurarea managementului, o echipa de dezvoltare experimentată, o reducere a costului, iar, în primele faze, posibilitatea validării timing-ului prielnic prin procedee de feedback incremental.

“Contextul tehnic și al mediului de business fiind potrivite, ne dorim să punem accentul pe modelul scalării pe verticală în relația cu clienții, motiv pentru care am decis să susținem 4 proiecte de incubare tehnică pentru companiile care pun accent pe inovație și evoluție digitală.

Mai mult, suntem mereu deschiși clienților noi, cu idei îndrăznețe, cărora să le oferim din start o echipă formată de ingineri în IT cu viziune antreprenorială. Ne dorim ca partenerii noștri să ne perceapă ca pe un “copilot tehnic”, cu care să se consulte asupra deciziilor de anvergură.

Privind componența echipei, aceasta va fi stabilită în funcție de nevoile specifice ale fiecărui start-up, însă elementele comune pentru fiecare colaborare, din punctul nostru de vedere, sunt reprezentate de calitatea soluției oferite, împreună cu implicarea ca asociat, aceste două puncte influențând vizibil succesul businessului cu care colaborăm.”

Shape OneShape TwoShape ThreeShape FourShape Five

The wind blows mainly in fall

I've read somewhere a story about a bunch of kids that were asked 'What makes the wind blow?'. Some of them responded 'The trees! The movement of the trees creates wind'. Even though the cute answer was obviously wrong, they noticed the essence of creating a change: it's always caused not by one individual or one object, it's caused by a synchronized effort of many shareholders, concurrently.

Timing - a way underrated aspect of entrepreneurship, a necessary condition for each and every startup, an esoteric field on which entrepreneurs make their move.

Timing can have in this context two different but equally important meanings. The first one, the internal timing, is about your drive to succeed, the right moment of starting a new adventure. Most people will search for the perfect moment for it and will have a lot of reasons why it isn't right now the perfect time to start working on their dream. Unfortunately, that moment will never come, either will be too early or too late, or you might feel that you don't know enough about the specifics. Moreover, you may never find out the consequences and ramifications of your actions and inactions. The wind, in this case, is your power to execute. To learn, research, talk to interested people, build, code, etc. But is that enough?

This timing will always depend on all the stuff that is going on in your life ( exams, job, getting married, kids, deaths and divorce ) and it should. In order to start something, you need to take into account and balance all those components and the risks involved. Are you ready to lose your job, your S.O. or even your house? Based on those decisions you can draw a mental-map of your situation and will put in balance the advantages and the disadvantages. The more you will figure out your situation, the more confidence you will have when putting your team together. If you are at peace with yourself, if everything is going great, if you have no expectations unmet, you will change nothing.

The second timing, the external timing, is correlated with the market, with the economic and even political situation of your desired place to start. You have to know the state of whatever market you are going to attack, the state of your future competition to effectively make decisions that will ensure the right path for you and your team. The principal reason why startups fail is 'no market need' but that does not mean only that the product is unusable or useless. Sometimes, that means that the market was not ready for you.

If you want the wind to blow, you better want that in autumn.

Shape OneShape TwoShape ThreeShape FourShape Five
1

Need something else?

Our focus is on bleeding-edge technology, business, entrepreneurship and leadership. If you have any questions about those, contact us to learn more.