Te ir darbs

te ir darbs

FitRadar ir jauna mobilo telefonu lietojumprogramma, kas lietotājam ļauj atrast vispiemērotāko personīgo sporta treneri vai sporta pasākumu Jūsu tuvākajā apkārtnē un jebkurā Jūsu izvēlētajā sporta kategorijā. Sports ir tuvāk nekā Jūs domājat. 

Galvenie pienākumi:

  • Būt daļai no FitRadar jaunuzņēmuma kā izstrādātājam un kā līdzdibinātājam, un aktīvi piedalīties FitRadar produktu izstrādē
  • Izstrādāt un uzturēt lietojumprogrammu iOS iekārtām atbilstoši izvirzītām prasībām un uzņēmuma iedibinātiem programmatūras izstrādes processiem

No Tevis sagaidām:

  • 3-5 gadu pieredzi programēšanā ar Swift
  • Spēju rakstīt viegli saprotamu, paplašināmu un uzturamu programmas kodu (atbilstoši “Clean Code” principiem)
  • Zināšanas par vispārējiem mobilo lietojumprogrammu izstrādes principiem, paradigmām, arhitektūrām un jaunākajiem virzieniem šajā jomā
  • Zināšanas par OOP, SOLID un Design Pattern
  • Zināšanas par iOS SDK, UIKit, CoreDate, Networking, Multithreading

Citas prasības:

  • Latviešu, krievu un angļu valodas zināšanas
  • Spēja pašam organizēt savu darbu
  • Spēja izveidot programmatūras izstrādes plānu un virzīt izstrādi atbilstoši izveidotajam grafikam
  • Vēlamā dzīves vieta: Rīga vai tās apkārtne

Pievienojies mūsu komandai un audz kopā ar mums kā uzņēmuma līdzdibinātājs!

Ja Jūs esat ieinteresēts, lūdzu sūtiet savu CV uz:

P.S. Visit our website: https://www.fitradar.me/ and join the mailing list. Our app is coming soon.

Being unique is not always a good thing

The other day I was reviewing my colleagues’ code. It was back-end code written in C#. I noticed that he introduced a class that is very similar to the structure I was quite sure existing in the .NET base library. I found that structure in Microsoft documentation and we agreed that it is better to use .NET type instead of introducing the same type with a different name. After that occasion, I recalled several other cases when I saw the unique solutions for the problems that could have been solved by well-known pattern or practice. My gut feeling was telling me then that it is not a good idea to introduce your own solution for a problem that is already solved by someone else, but I have never really thought what problems such decision can introduce in the project. And so in this article, I wanted to share some thoughts regarding the widely accepted and unique solutions in software development.

First let’s make it clear that any best practice, framework, algorithm or technology was a unique solution in their time. Then when exactly one or another solution became widely accepted?

  • There are solutions in computer sciences that can be measured, like algorithms. In order to estimate the cost of algorithm calculation Big O notation was introduced. When someone comes up with a new algorithm for common problem, for example sorting, we can simply compare how fast each algorithm solves the problem using big O, and choose the one that meets our criteria. And if the new algorithm beats the old one in performance working on the same data, then it becomes the new standard.
  • But most of the technologies, frameworks, patterns and best practices can not be compared by introducing measurable parameters. Think about programming languages or frameworks. There is noway you can make an unambiguous claim which language or framework is better. Then how to find out what is the best language or framework for the given problem. Let me share a story from my youth that might give some insight how the new solution become widely accepted. I remember the story that was shared by my Assembler class professor at University. He started his computer scientists career when software was written in punch cards and he became very good at writing machine code and later at Assembler. And when the first compilers emerged such as FORTRAN and ALGOL he was very skeptical regarding these new languages and the compiling technology in general, because he didn’t believe that the compilers algorithm is able to produce the same quality machine code as a skilled Assembler developer. And in the fifties and sixties well written assembly code really metered, because every byte was counted and his reasoning at that time was valid. But time passed by the hardware and compilers improved and we see that most of the code even in embedded systems now days is written in high level programming languages. The same story goes for programming paradigms – the business application world started with procedural programming and today it ended with Object oriented programming. In Windows and Mobile apps we started with Forms and Activities and today ended with MVVM. So it looks like for such things as programming languages and frameworks more or less useful criteria that we can use is
    • the amount of time the technology is used,
    • amount of software written using the the particular technology
    • number of developers actively using the particular technology

And still all these criteria are not so reliable as big O for algorithms.

In case of algorithm I think it is quite clear that if there is already an algorithm that solves the problem it is pointless to write your own, unless you can produce better one. In case of frameworks I would follow the same logic – if there is an well known framework that can solve the problem it is much safer to relay on the majorities opinion (although the majority can be wrong) rather than on your own single point of view. Even if the framework or pattern will be rejected in the near future at this moment:

  • it is much more tested than your own solution, and therefore there are much more chances to have a flaw or even bug in your solution than in the widely accepted solution
  • it will be much easier for other developers to work with widely accepted solution than yours, because there is much more documentation and all kind of sorts information about the widely accepted solution than you can ever produce. And this will become crucial when your solution will start to live it’s own live

Visit our website: https://www.fitradar.me/ and join the mailing list. Our app is coming soon.

P.S. We are hiring: http://blog.fitradar.me/we-are-hiring/

We are hiring

We are hiring

FitRadar is a new free app to find the best personal trainer or sports events in your local area, in any sport. Fitness is closer than you think. Coming soon.

Key responsibilities:

– Be part of a FitRadar startup team and actively take part in developing the products

– Develop and maintain application software working with established processes

Job requirements:

– 3-5 years of development experience with Swift

– Ability to write consistent, well-documented code (Clean Code)

– OOP, SOLID principles

– Familiarity with the generic mobile development paradigms, architectures, current trends

– iOS SDK, UIKit, CoreDate, Networking, Multithreading

Personal skills:

– Russian, Latvian and English

– Location: Riga or Latvia

– Analytical thinking and self-driven

Join our team and grow with us as co-founder.

If you are interested, please share your resume:

PERSONĪGĀ TRENERA IZVĒLE

personal trainer

Nav ne jausmas, kuram no neskaitāmajiem instruktoriem sava ķermeņa slīpēšanu lai uztic? Šāda jautājuma esamība jau vien liecina par lielisku startu. Šajā publikācijā lasi, pēc kādiem kritērijiem īsto „mentoru” izvēlēties.

Vienmēr paturi prātā: tavs personīgais treneris ir cilvēks, no kura atkarīgs tavs fiziskais stāvoklis un veselība – augsta kompetence un profesionālisms ir pamatu pamats. Cilvēks, kas pārzin tava ķermeņa īpatnības, tā sagatavotības līmeni, kā arī vingrinājumu tehnikas trenažieru zālē vai grupu nodarbībās, tikt pie vēlamā rezultāta palīdzēs krietni ātrāk.

Iesākumā iekal prātā, ka personīgais treneris ir obligāts nosacījums produktīvai sportošanai. Viņš ir galvenais palīgs ceļā uz perfekto svaru un augumu. Bez trenera iztikt spēj ja nu vienīgi… pats treneris. Bez šāda speciālista, nepārzinot konkrētu izpildes tehniku un trenažieru darbības principu, tu vari lieti sev kaitēt. Tā kā esam tendēti uz rezultātu, un nevis traumām, piedomāsim pie tā, kur lai cienīgu kandidatūru atrod.

Kam būtu jāpievērš uzmanība

Būtiskākais trenera darba kvalitātes rādītājs ir nevis tas, kā izskatās viņš pats, bet gan viņa darba augļi – klienti. Lai gan šis apgalvojums ir diskutējams, daiļrunīgākais apliecinājums profesionālismam ir rezultāti. Ja tava trenera mācekļi ir slaidi, plakanu vēderu un augstu trenētu pēcpusi, tātad, izvēli esi izdarījis pareizo.

Īsts profesionālis ne vien sniedz rekomendācijas, bet gan izmēģina tos uz sevis. Treneris, kas netrenējas pats – indikators, ka ir vērts piedomāt par tā nomaiņu.

Esi vērīgs jau pirmajā treniņā. Ja treneris, neizzinot tavu potenciālu un neiztaujājot par tavu veselības stāvokli, uzveļ tev pamatīgu slodzi uzreiz, diez vai viņš saprot, ko dara. Vai arī uzreiz sāk veidot tievēšanas treniņu plānu. Lai sastādītu kompetentu apmācību programmu, vispareizāk, lai pirmās nedēļas garumā viņš ieņemtu vērotāja pozīciju, novērtējot tavas iespējas. Ja uzdevumu izpildes laikā sajūti sāpes, konsultējies ar ārstu.

Kad esiet viens otru atraduši

Nespēlē pasīvo lomu pats sevā izrādē: ja treniņu programma ir sastādīta tev – tev ir visas tiesības piedalīties tās pilnveidē. Ja vēlies panākt ar treneri absolūto sapratni, uzdod jautājumus, izrādi iniciatīvu. Esi godīgs: nevaino viņu par liekajiem kilogramiem, ja slepeni aizraujies ar saldumiem – šādi tu ievedīsi treneri strupceļā. Stāsti par visu: par rezultātiem, par sasniegumiem, toskait arī par slodzes laikā sajusto diskomfortu.

Ja neesi savā trenerī vēl pietiekami pārliecinājies, tikt skaidrībā ar izvēles pareizību var līdzēt pāris jautājumi. Neuzkrītoši uzdod tos sarunā ar treneri. Palūdz pastāstīt par gaidāmo treniņu plānu – viņam būtu jāizklāsta pilns iepriekš sastādītais treniņu plāns, nevis jāģenerē idejas no vietas.

Būtiski arī, lai treneris izklāsta, kā vislabāk pēc treniņiem atjaunoties – vai ir vērts pavadīt brīvo dienu uz dīvāna vai veltīt to nesteidzīgam kardio.

P.S. Apmeklē mūsu mājaslapu: https://www.fitradar.me/

P.S.S. Original text: https://vp.lv/blogs/raksti/personiga-trenera-izvele