DEV Community: Kirill Shirinkin

I've built a speech to text app for my wife. Here is how.

Kirill Shirinkin — Wed, 18 Nov 2020 06:24:30 +0000

My wife is finishing her thesis at the moment. 👩🏻‍🎓 As part of this thesis she needed to conduct around a dozen hour-long interviews, then transcribe them to text and do some analysis of it (all in German language). She was telling me how huge the task of transcribing audio to text will be and how she will need hours and hours of extremely unrewarding work to do it. 🙇🏻‍♀️

Being a developer and a cloud infrastructure engineer myself, I helped her out and built an app. In this app, she could upload her audio files and get an accurate transcription back.

Having the backbone of the app ready, it was quite simple to make an actual production app out of it, and this is exactly what I did. Here I want to share some technical decisions that helped me to ship the complete product in around 8 weeks, working on it mostly on weekends and late evenings. In total it took me around 25 hours to build it.

Rails

The complete application is written in Ruby, with Ruby on Rails. This is by far my favourite framework since more than a decade to create web applications. As always with Rails, I was able to add many things like authentication and authorization, file storage, sending emails, admin interface, background job processing etc etc.

One new thing I did differently this time is using Que for background processing. I wanted to keep the total number of components to maintain as small as possible. Most of the background processing workers require another persistence layer, be it Redis or SQS or something else. Que stores and processes jobs from the same database as the application, PostgreSQL in case of Transcripto.

Stimulus

Extra credit goes to StimulusJS. I am not a frontend developer, but I really like Vue.js - it allows writing nice, maintainable, components-orieneted frontend without doing complete SPA thing. With Vue I can just sprinkle interactive components over different parts of the application.

Same applies to Stimulus, but it's even simpler and easier to use. I've tried it on two projects including Transcripto and I love the simplicity of it. Of course, this application has minimal requirements to frontend, but if you are making an app that doesn't need to be full-grown SPA, then I recommend taking a look at Stimulus.

AWS

The infrastructure layer is completely built on AWS. I've used AWS S3 (and S3 Event Notifications), SNS, SQS, ECS Fargate, Transcribe, Aurora Serverless. Standard services, like CloudWatch, VPC and IAM are also part of the stack of course.

Managing this number of cloud resources, across two AWS accounts (one for preprod and one for prod) in a proper way could be a challenge. For my clients I normally would use Terraform, as I believe it's superior to CloudFormation. But for Transcripto I've tried something new - AWS Copilot

AWS Copilot

AWS Copilot is a new CLI for building and deploying apps on AWS. It's pretty new, but it's already great. It makes managing aforementioned AWS resources and linking multiple AWS accounts, setting up CI/CD pipeline (with CodeBuild and CodePipeline) very easy.

If you are starting a new product on top of AWS, I highly recommend looking at Copilot. It saved me may be 5-6 hours of time, if not more. And yes, in the end it generates a lot of CloudFormation templates, but it's care case where I can live with this.

Misc

Other essential tools:

ffmpeg - for audio analysis;
GitHub - for source control;
Figma - for design (my co-founder of mkdev.me, Leo, used it);
Bootstrap - still easiest way to do good looking responsive web site;
Rollbar - exceptions tracking;
Freshdesk - for free ticketing system;

I will talk about many parts of the stack in depth on mkdev YouTube channel.

Transcripto was a fun side project to do - I tried a bunch of new things and helped my wife a lot, already a win-win situation.

It's far from perfect - there are many things I want to improve both on infrastructure and application sides. But I hope this tool will make lives of many students and journalists much easier.

You can see the full stack on Transcripto's StackShare page.

Would you hire a mentor?

Kirill Shirinkin — Sun, 24 Jun 2018 09:22:27 +0000

dev.to, help me out with opinions :) If there would be a service to hire a programming mentor on weekly basis (payments per week/month), and this mentor would help you define your career goals (learn new tech, learn programming from scratch, develop pet project), tell you how to get there, answer all your questions, review all your code etc. etc. - would you pay for that? What would you expect from such a mentor?

Note: not to be confused with short voice consultations.

Google Pixel vs. iPhone 7 or how programming languages are being chosen in real life

Kirill Shirinkin — Sun, 22 Oct 2017 15:56:08 +0000

Original is posted on mkdev.me

Some time ago, even before Leonid Suschev and I released Specializations on mkdev.me, we were discussing their possible contents for the god-knows-which time. Those discussions were exhausting and wistful and could even make the whole industry look repulsive. Classifying IT knowledge is a rather ungrateful task. For some the outcome would be unsatisfying and some would be even outraged with it.

Here are some questions that we’ve come across:

Should we distinguish the Ruby on Rails development as a separate specialization?
Should we distinguish some specific JavaScript frameworks into separate specializations?
Should we make a separate specialization for Chef and Puppet?

And that went on and on. Here you can find the result of all the discussions: mkdev.me/en/specializations.

What’s interesting is that Leonid doesn’t have a clear apprehension of programming and all the related topics. That’s fine, as here, on mkdev we teach people like that: with almost zero knowledge, those who don’t know what to do and what to choose, but fiercely want to get the hang of it. So I had to occasionally explain some details, global aspects and magic of the development.

Once, the conversation turned on Django and Ruby on Rails. Leonid tried to understand the fundamental difference between two web-frameworks, the difference which allows choosing between one and the other, when you have the particular technical specifications. The conversation took a sudden turn:

— What’s the actual difference between Python and Ruby?

— They’re as chalk and cheese. Absolutely different programming languages.

— So that means that Rails and Django have absolutely different app-creating capabilities too.

— Nope, the same.

— Then why is Yandex written using Python, and not Ruby?

— It’s written with dozens of languages, including Ruby and Python.

— And why not to use only one language? Why is something written with Ruby and something with Python?

And seriously, why? To answer that question I could have babbled about the fact that Python is perfect for the data science tasks and Ruby is the best solution for the small scripts and that’s why you need to use this and that. I could have also added that sometimes the speed of those particular languages is not enough, so the exemplary Yandex might also use Go for the speed-demanding components. That would be an accurate and satisfying response for any other co-founder and probably for any other digital-savvy interlocutor. After all, this also answers the other Leonid’s question about those fundamental differences in technologies:

— Why are some walls in this house made of wood, some of stone and some of glass? Why don’t we make all of them out of wood?

Indeed, the person ignorant of IT or a Junior developer that just started can think that the choice of a programming language or between two frameworks depends on some technological aspects. It might look like you pick either a hammer or a screwdriver in a situation when you just need to tap a nail in. Of course you need a hammer! But a screwdriver might come in handy too someday! That’s why the exemplary Yandex uses Ruby, Python, as well as C++ and C and lots of other things. Is that so? Well. Probably, it is. But that’s not the entire truth.

In fact, when you’re picking the technology, it might seem like you choose between a flagship iPhone and an Android phone. The reasons why you pick one or another are pretty close to the ones when you choose the technology, at least.

John bought his first iPhone back in 2010 and he can’t live without it since then. It’s convenient for him to make calls, take pictures, text and surf the Internet with it. He has no reasons to change it, as things are going well in Apple. Almost all John’s friends have iPhones except for one stubborn James. He bought his first Android phone back in 2010 too. It’s convenient for him to make calls, take pictures, text and surf the Internet with his Google Pixel.

James always tries to encourage his Apple fan friends to have an Android instead, but lacks the arguments. Since there are no fundamental differences between his flagship Pixel and an iPhone 7.

James is not like his neighbor Bob, who has an Android too. Bob always calls iPhone users stupid iSheep and fervently tries to prove that Android is better. No one dares to contradict him, but his arguments are enough only for those who have similar mentality.

Once John (the one with an iPhone, remember?)gets a job in some company called WagnerCom. There he receives a corporate Android phone. So he has to use it for business issues and his iPhone for personal ones. After some time he gets used to Android. Now it’s equally as convenient for him to use an iPhone as an Android phone. He agrees with James that Android is better in some aspects, but also knows that in some other aspects he would prefer iPhone.

John has a son Michael, who’s into gadget-related web-sites. Reading some of them, he finds out about the phone which uses a brand-new experimental platform NonameOs. So Michael jailbreaks his iPhone and installs NonameOS.It works like crap, there are few apps, but it’s a basically new platform though. He hangs out with other 100 people on the message board, each of those wholeheartedly uses NonameOS. They believe that the right concepts of the right platform will win one day and NonameOS will win and will be on the same level with iPhone and Android, and then will even exceed them. And then all the people will be able to make calls, take pictures, text and surf the Internet with NonameOS phone.

And let’s not forget about James’ colleague William. William is in urgent need of the dual-SIM phone. That’s important, as he cannot afford having two phones but he definitely needs two SIMs. He has no choice but to buy some rare Android phone with a dual SIM option. There is no choice for him since there are no dual-SIM iPhones.

So now we have John, James, Bob, William and hundreds of thousands or even millions of people, each of those inclined to some particular phone. The choice might have been imposed by the social circle (of colleagues or friends), by the consumer marketing; or you might have bought it simply because you wanted to stand out of the crowd. And this goes on and on. But the result is that each of us can make calls, take pictures, text and surf the Internet with his or her phone. And actually there’s no huge difference in what to use for that.

There’s no some distinctive difference in what to use to write a web-app. You can use Django, you can use Rails or even Node.js. There’s no difference what to use to automate servers too. Both Chef and Puppet appeared at the same time and solve similar problems in a similar way. You can live with MySQL instead of PostgreSQL, if your new employer uses PostgreSQL all of a sudden. When you rewrite some slow parts of the app, you use something faster than Ruby, something like Go, Scala or Erlang.

The choice of technology stack is not a serious engineering project. It’s not a choice of the best instrument based on the technical requirements.
It’s not a choice between a hammer and a screwdriver. It’s a choice based on the specifications, historical reasons, job marketplace situation, personal preferences, expertise, habits and interests of the developer team, quality of marketing materials, susceptibility to marketing and hype of the people who work in the company.

Facebook uses PHP, because a long time ago a young student Zuckerberg knew it and it was faster for him to write Facebook using PHP. And afterwards it just didn’t make any sense to rewrite it completely.

Another fact, Facebook uses Chef, because someone from the company heard about it more than about Puppet. They also use Ruby, as they use Chef.

There’s definitely Go hidden somewhere too, because some SRE was bored and in his off-duty time he tried to use it and rewrote some internal services with it. Then he persuaded his colleagues that it’s a great idea. Why Go? It’s overhyped, it has many new instruments and it might be a nice CV entry in case he wants to quit.

Of course, there are some obvious no-choice situations when you choose technologies for some particular reasons. We have to use Swift when we create fully-fleged iOS games just like William has to use dual-SIM phone. Such limitations inspire to some extent. You don’t have to choose between two similar hammers, there’s a ‘golden stack’ of instruments.

Nothing stops you from using the same language for absolutely everything in most cases. We use Ruby, because it’s comfortable and fun for us. Then we rewrite some parts of the app using Go, because Ruby wasn’t fast enough and because Go is awesome. And we can include Spark-apps written with Scala. And then let’s try to explain to a non-programmer, why we couldn’t just use Scala in the first place and write the entire app and all its services using Scala. Or why couldn’t we just use Ruby for everything and fund the servers so they would work faster.

— This is so stupid. Why then do you write different parts of the app using different languages?

And seriously, why?