DEV Community: ViksaaSkool

Fortran meets AI

ViksaaSkool — Sun, 15 Mar 2026 17:32:51 +0000

Story time

My father studied at Faculty of Electrical Engineering at SS Cyril and Methodius University in Skopje in the late 70s.
I studied at the same faculty and university 30-something years later and got my Master's degree at Faculty of Computer Science and Engineering.
While back, during my studies I found one textbook from the courses he took, Fortran IV. Here's the photo of it:

Some of you reading this might know what Fortran is (programming language), but I presume almost none of you seen problems solved in the language or punch cards. Yes, punch cards. Back in the days, people used to code on punch cards and that was included in this course. Punch cards meant that every line of code in a program had to have its own card. So if your program had 1000 LOC, then you had 1000 cards. How that looked, more in this video:

Most interesting thing: there was an exam inside it, his exam from almost 50 years ago! Here it is (fyi, the language is Macedonian):

As you can see they weren't solving important problems back in the day like, recommendation algorithm or even more important and harder to grasp, CSS. It's mostly useless math.
Even though I've known about this exam for quite a while and wanted to solve it, never got to it. Until now.

Today

With everything that's happening in the field of computer science and AI, writing code and solving problems is the easy part. But an exam 50 years ago in Fortran? Would that be a problem for today's best models? You've guessed it right - it won't.

I've made a small showcase GitHub Page with the solutions to these 5 problems, called Fortran meets AI you can visit here.

The same problem is solved by Claude Code (Opus 4.6), Codex 5.4 (by OpenAI) and MinMax 2.5 from China.

Results

Codex had no problem in reading, recognizing and solving the issues. The model was provided with the images, translated it to English and created two .svgs. It produced solutions in Fortran, Python and Kotlin.
Cladue Code had no issue to resolve this, provided the solutions for the problems in Fortran, Python and Kotlin.
MinMax 2.5 the free version provided by OpenCode's OpenZen (which I've used) cannot read images, so I used the .svgs that Codex created. Had no issues
I've added Python compiler (it was the easiest) so solutions can be compared in terms of compile speed and simplicity. And with that you can clearly see that Codex gave "uncopilable" solution on the second problem (SyntaxError: '(' was never closed). The only model that did this, which, to be honest, I didn't expect.
Even more surprising, Claude Code got the first task wrong, MiniMax did it most optimal, made mistake in Problem 2.

In details:

Last, not least, Claude code was the only one to include the input card layout in the solution, for example:

Words of wisdom

If you got to here by reading, you deserve a smart sounding sign off to this article. From this stand point programming and software engineering in the late 70s looked pretty bleak and like nothing that can guide our lives in such an important manner as today. It took new technologies and discoveries to place it as one of the guiding forces of current and future progress. To that note, maybe today's state of SWE will look as bleak and simplistic as Fortran in the 70s. Matter of fact, I'm sure of that and that day is coming rather sooner than later.

AI, tech and society: educated fool’s predictions

ViksaaSkool — Wed, 21 Jan 2026 22:56:21 +0000

The original post was written in late 2023, edited and changed in the first months of 2024, but never published, because I was persuaded by some peers who had a glimpse into it that it was too dark and negative. Two years later, here it is — I published it as is (only with some small formatting changes). Now, with a bit of pride that I got most things right (in these two years), I plan on writing part two, with more predictions on how the changes might affect society and what the possible end results are (in more detail).

Intro

I have a bachelor’s and master’s degree in computer science, specializing in intelligent information systems. I have 12 years of experience as a software engineer — I started with web development but quickly switched to the then shiny new(ish) thing: Android development. I’ve been at different points in the software engineering process, down in the trenches and outside, overlooking the deadline release battles. I’ve worked at startups, digital agencies, and product-based large companies — from “it doesn’t matter — let’s ship it” to “the name of this variable in your unit test is not intuitive enough.” I’ve worked on passion projects, blogging, published a somewhat popular Android library, done data science in Python, and tried to center a div in CSS. I consider myself a valuable addition to a software engineering team — knowledge, experience, creativity, and some bad jokes in stand-ups.

I’m humble enough to know that I’m replaceable — as a software engineer or researcher, a very strong and genuine “will be missed,” but still replaceable. Looking in the eyes of the upcoming AI development automation, we, software engineers, will all be humbled and sooner or later come to the same realization.

The post-pandemic tech market was booming; the abundance of job opportunities was overflowing the tech fountain of career perspectives. This resulted in inflated tech employment and the creation of a big cushion of the software engineer’s comfort, who has been able to indulge in conspicuous consumption more than ever. Everything started to shift with global political events, which were aided by the introduction of ChatGPT. Ever since that moment, there has been progress in tooling that erodes, bit by bit, the rock of software engineers’ responsibilities, narrowing down the job description.

The aim of AI iterations is to reach a point where it can do everything a human would do, without emotions and imperfections. The end goal is to create a know-it-all entity, also referred to as artificial general intelligence (AGI).

If you look into the software engineering corners of the internet, the theme playing out loud is “Will I be replaced by AI?” — and I’m going to try to answer that and make a prediction. Hopefully a good one.
Drumroll, the answer is: yes. Let me elaborate.

Predictions

My predictions are going to be centered around tech and how those changes will affect society. To be noted, there’s no branch of the economy that will not be affected in a substantial manner.

1) The changes will happen in waves of invention and adoption – even if the invention moves exponentially the adoption will slow down the pace. How much, remains to be seen.

First wave. We’re currently in the first wave, where LLMs are packaged in the form of tools that are good enough to aid the developer in the daily work. Some very repetitive parts of the engineering process are easily replaceable with the tools being available. Mainly, it’s just an addon to what developers already do, but helps with productivity and brings value to the shareholders. Jobs like translators, content writers, manual QAs can be rendered obsolete, but are not. The industry sees a shift and is reluctant for new investments into hiring people, rather than developing these tools, or waiting for these tools to be developed. Minor adaptations already have begun, but very few companies have official and firm stances. Data privacy is still not resolved, one of the many reasons why companies are hesitant to start applying the new tech on mass. This is where the people that say “you’re most likely not going to lose your job (because of AI)” are right. We have 1–2 years left from the first wave.
Second wave. Tools like Devin and more to come (AutoDev from Microsoft?) become good enough to replace junior devs and do most of the work. Data privacy is resolved, and more companies start to embrace the “AI dev” tools. First AI Dev digital agencies appear – offering packages to companies for “subscribing” to their dedicated AI team of devs. Very few new openings are going to be posted, low demand, high supply. Layoffs are going to have their moment – each next round will be higher than the previous one. This won’t be happening just in tech, but also in most data-driven industries. The new tech is going to produce tools to replace other job descriptions, while it also eats itself – a truly poetic end. This is when you’d be really worried about your job if you still had one. Getting a job once you got laid off will be harder than ever, close to impossible. The economy shifts are going to be apparent and first “organic” software movements are going to appear. The push back from developers (and other workers that were laid off) is going to take some form. A lot of talent is going to be unemployed and that talent and experience, with the help of the very same AI that got them in that position, will be able to compete against the now very big companies. If there’s no legal intervention and most of the AI breakthroughs stay open, big tech is going to be under threat in terms of monopoly. Building complex systems will be easier than ever, an opportunity that a sizable chunk of the unemployed devs will take. I expect this wave to last 2025–2035.
Third wave. This is going to be a period that is mostly adaptation and social amortization of the automation consequences. How societies are going to handle the second wave will determine what will happen in the third one and what pace AI adoption will have. Tech is going to be focused on displacing all other jobs that are now considered safe – manual labor jobs that need more context and require multiple models to cooperate. With advancements in robotics this will be achieved. Home robotic appliances for ironing shirts and folding clothes will be good enough that no human assistance will be needed. It’s unlikely, and I’d be very surprised, if by this time we achieve AGI, but some pretty good forms of it are going to be out there. I expect this period to be 2035 until a viable AGI is introduced.

2) NO, AI won’t “create more jobs than it’ll displace”.

The “new jobs” that are going to be created will be narrow, harder for novice developers to do and/or to be seen as eligible by companies. The price of labor will drop, and tech won’t be an attractive field to get into.

Social consequences of automation

Society is built on norms and rules that make the system run. The massive introduction of AI will challenge most of the norms and all the rules that have built modern societies. The very basic rules of setting up the social hierarchy, climbing the social ladder, through actions of acquiring resources because of work, will be diminished or totally nullified. The stability of the system depends on how fast this change is going to happen and how it will be handled.

Almost certainly we're going to see economic turbulence in the short run, followed by very probable social unrest and some dystopian form of new society as the end result.

Most likely outcome will be frozen or very inert social mobility, two main classes:

The "organic" oligarch/winners of AI revolution class. They'd be able to enjoy goods and services developed and produced by people, not because they are better, on the contrary because they can afford their costliness. Form of status signaling. Art, movies, food, barbers, designers - everything human made.
The rest, the synthetic class. The consumers of the "free" products of AI - basic goods and services enough to live lives happy enough not to rebel or revolt and not good enough to afford the "organic" luxury.

(Idea + Sensors + Compose + Lottie)*AI Agents = Beautiful UI

ViksaaSkool — Tue, 06 Jan 2026 02:38:38 +0000

Idea

In the AI era of software development, the doing part has become significantly cheaper — especially in terms of time. Complex ideas are now just a prompt away from becoming an MVP.

This shift means that standing out is no longer about what you build, but how well you build it. Quality, polish, and thoughtful UX are what separate good products from forgettable ones.

In this post, I’ll walk through a step-by-step guide to implementing a widely used UI widget: a steps counter component that visualizes a user’s daily activity as progress toward a goal (typically 10,000 steps).

The component features an animated humanoid figure that mirrors the user’s activity — when the user walks, the figure walks; when the user is idle, the figure remains still. Color is used as a second signal: progress shifts from red (far from the goal) to green (close to completion).

The goal is to demonstrate how small details and animation can turn a standard metric into a more engaging, human-centered experience.

Sensors

The first thing that needs to be done is to create a mechanism that tracks movement.

it needs to be able to tell if the user is indoor or outdoor.
if it's indoor it should rely on sensors - Sensor.TYPE_LINEAR_ACCELERATION and Sensor.TYPE_GYROSCOPE
if it's outdoor it should rely ActivityRecognitionResult, i.e. distinguish between DetectedActivity.WALKING, DetectedActivity.RUNNING and DetectedActivity.ON_FOOT in MotionTransitionReceiver

For that I need to update the AndroidManifest.xml:


<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/>

    <uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />

and


<receiver android:name=".motion.transition.MotionTransitionReceiver"
            android:exported="false" />

Then, the more important part:


//how we request updates 
fun ComponentActivity.requestActivityUpdates() = ActivityRecognition.getClient(this)
    .requestActivityUpdates(
        1500,
        getMotionPendingIntent()
    )
    .addOnSuccessListener {
        Timber.d("Periodic updates registered")
    }

//simple way of deciding if the user is indoor or outdoor 
fun Location.isLikelyOutdoors(): Boolean {
    val goodAccuracy = accuracy <= 20f
    val hasAltitude = hasAltitude()
    val hasBearing = hasBearing()

    return goodAccuracy && (hasAltitude || hasBearing)
}

Two listeners (OutdoorStateListener and MotionBasedOnSensorListener) are defined so they can be passed around.

interface MotionBasedOnSensorListener {

    fun start()
    fun stop()
    val isMoving: StateFlow<Boolean>
}

interface OutdoorStateListener {

    fun start()
    fun stop()
    val isOutdoor: StateFlow<Boolean>
    val shouldRequestPermission: StateFlow<Boolean>
}

MotionBasedOnSensorDetector main idea is represented in:


class MotionBasedOnSensorDetector @Inject constructor(
    @ApplicationContext val context: Context
) : SensorEventListener, MotionBasedOnSensorListener { 

    private val _isMoving = MutableStateFlow(false)
    override val isMoving: StateFlow<Boolean> = _isMoving

//...

    override fun onSensorChanged(event: SensorEvent) {
        val values = event.values
        val magnitude = sqrt(values[0] * values[0] + values[1] * values[1] + values[2] * values[2])

        val now = System.currentTimeMillis()

        val moving = when (event.sensor.type) {
            Sensor.TYPE_LINEAR_ACCELERATION -> magnitude > thresholdAccel
            Sensor.TYPE_GYROSCOPE -> magnitude > thresholdGyro
            else -> false
        }

        if (moving) {
            lastMovementTime = now
            _isMoving.value = true
        } else {
            if (now - lastMovementTime > 1200) {  // 1.2s without movement
                _isMoving.value = false
            }
        }
    }


}

While OutdoorStateMonitor is implementation of OutdoorStateListener:


class OutdoorStateMonitor @Inject constructor(
    @ApplicationContext val context: Context
) : OutdoorStateListener {

//...
private val callback = object : LocationCallback() {
        override fun onLocationResult(result: LocationResult) {
            val location = result.lastLocation ?: return

            val isOutdoor = location.isLikelyOutdoors()

            if (lastIsOutdoor != isOutdoor) {
                lastIsOutdoor = isOutdoor
                Timber.d("OutdoorStateMonitor | isOutdoor = $isOutdoor, acc=${location.accuracy}")
                context.debugToast("isOutdoor = $isOutdoor, acc=${location.accuracy}")
                _isOutdoor.value = isOutdoor
            }
        }
    }

As stated in the AndroidManifest.xml, there's a MotionTransitionReceiver that is defined as:


class MotionTransitionReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        if (ActivityRecognitionResult.hasResult(intent)) {
            ActivityRecognitionResult.extractResult(intent)?.let {
                val activity = it.mostProbableActivity
                Timber.d("Periodic update = ${activity.type.toActivityName()} confidence=${activity.confidence}")
                context.debugToast("onReceive() | event = ${activity.type.toActivityName()}, confidence=${activity.confidence}")

                val moving = activity.type == DetectedActivity.WALKING ||
                        activity.type == DetectedActivity.RUNNING ||
                        activity.type == DetectedActivity.ON_FOOT

                MotionState.setMoving(moving)
            }
        }

This forms the basic simple, heuristic for the detection of movement that needs to be managed into a ViewModel that, then in UDF fashion communicates with the UI:


@HiltViewModel
class StepsViewModel @Inject constructor(
    val outdoorStateListener: OutdoorStateListener,
    val motionBasedOnSensorListener: MotionBasedOnSensorListener
) : IStepsViewModel() {

    private val _shouldStartMotionTransition = MutableStateFlow(false)
    override val shouldStartMotionTransition = _shouldStartMotionTransition.asStateFlow()

    private val _isMoving = MutableStateFlow(false)
    override val isMoving = _isMoving.asStateFlow()

//...

init {
        collectShouldRequestPermission()
        outdoorStateListener.start()
        collectOutdoorStateChange()
    }

    private fun collectOutdoorStateChange() = viewModelScope.launch {
        outdoorStateListener.isOutdoor.collect { isOutdoor ->
            Timber.d("collectOutdoorStateChange() |  isOutdoor = $isOutdoor")
            if (isOutdoor) {
                _shouldStartMotionTransition.value = true
                motionBasedOnSensorListener.stop()
                collectMotionTransitionState()
            } else {
                _shouldStartMotionTransition.value = false
                motionBasedOnSensorListener.start()
                collectMotionBasedOnSensor()
            }
        }
    }

//...

}

Compose + Lottie

Second, compose component needs to be created. A circle that needs with lottie animation in the center.
The easy part - drawing the animation. The hard part making the lottie animation tintable.


@Composable
fun CircularFillWithLottie(
    modifier: Modifier = Modifier,
    progressPercentage: Int,
    fillColor: Color = Color.Green,
    backgroundColor: Color = Color.LightGray,
    strokeWidth: Dp = 8.dp,
    animationDuration: Int = 800,
    animationEasing: Easing = FastOutSlowInEasing,
    lottieRes: Int? = null,
    isMoving: Boolean = true
) {
//...
}

//and then the most important component: 

@Composable
fun TintableLottie(
    @RawRes lottieRes: Int,
    fillColor: Color,
    isPlaying: Boolean = true,
    iterations: Int = LottieConstants.IterateForever
) {
    val composition by rememberLottieComposition(LottieCompositionSpec.RawRes(lottieRes))

    val lottieAnimState = animateLottieCompositionAsState(
        composition = composition,
        isPlaying = isPlaying,
        iterations = iterations
    )

    val fillProperty = rememberLottieDynamicProperty(
        property = LottieProperty.COLOR,
        value = fillColor.toArgb(),
        keyPath = arrayOf("**")
    )

    val strokeProperty = rememberLottieDynamicProperty(
        property = LottieProperty.STROKE_COLOR,
        value = fillColor.toArgb(),
        keyPath = arrayOf("**")
    )

    val filterProperty = rememberLottieDynamicProperty(
        property = LottieProperty.COLOR_FILTER,
        value = SimpleColorFilter(fillColor.toArgb()),
        keyPath = arrayOf("**")
    )
    val properties = rememberLottieDynamicProperties(
        fillProperty,
        strokeProperty,
        filterProperty
    )

    val dynamicProps = remember(fillColor) {
        properties
    }

    LottieAnimation(
        composition = composition,
        progress = { lottieAnimState.progress },
        dynamicProperties = dynamicProps
    )
}

Note: the lottie animation was found on lottiefiles.com.

To make things come together, one separate component, MotionDetector needs to be implemented with the sole purpose of fetching the motion data and passing it into the UI. That's done in this manner:


@Composable
fun MotionDetector(
    stepsViewModel: IStepsViewModel = hiltViewModel<StepsViewModel>(),
    onMovementChange: (Boolean) -> Unit
) {
    val activity = LocalActivity.current
    val shouldStart by stepsViewModel.shouldStartMotionTransition.collectAsState()
    val shouldRequestPermission by stepsViewModel.shouldRequestPermission.collectAsState()
    val isMoving by stepsViewModel.isMoving.collectAsState()
    onMovementChange(isMoving)
    if (activity is ComponentActivity) {
        val permissions = arrayOf(
            Manifest.permission.ACTIVITY_RECOGNITION,
            Manifest.permission.ACCESS_FINE_LOCATION,
        )

        val launcher = rememberLauncherForActivityResult(
            contract = ActivityResultContracts.RequestMultiplePermissions()
        ) { results ->
            val allGranted = results.values.all { it }

            if (allGranted) {
                activity.requestActivityUpdates()
                if (shouldRequestPermission) {
                    stepsViewModel.onPermissionGranted()
                }
            } else {
                Toast.makeText(activity, "Permissions denied", Toast.LENGTH_SHORT).show()
            }
        }

        val allGranted = permissions.all {
            ContextCompat.checkSelfPermission(activity, it) == PackageManager.PERMISSION_GRANTED
        }

        LaunchedEffect(shouldStart) {
            if (shouldStart) {
                if (allGranted) {
                    activity.requestActivityUpdates()
                } else {
                    launcher.launch(permissions)
                }
            } else {
                activity.removeActivityUpdates()
            }
        }

        LaunchedEffect(shouldRequestPermission) {
            if (shouldRequestPermission) {
                launcher.launch(permissions)
            }
        }

        DisposableEffect(Unit) {
            onDispose {
                activity.removeActivityUpdates()
            }
        }
    }

}

And then the final component:

@Composable
fun StepsContainer(stepsViewModel: IStepsViewModel = hiltViewModel<StepsViewModel>()) {

    var isMoving: Boolean by remember { mutableStateOf(false) }
    var progressPercentage: Int by remember { mutableIntStateOf((0..100).random()) } //this needs to be real value from health api

    MotionDetector(stepsViewModel) {
        isMoving = it
    }

    Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
        Box(
            modifier = Modifier
                .fillMaxSize()
                .padding(innerPadding),
            contentAlignment = Alignment.Center
        ) {
            CircularFillWithLottie(
                progressPercentage = progressPercentage,
                modifier = Modifier.size(150.dp),
                fillColor = progressPercentage.toProgressColor(),
                backgroundColor = Color.LightGray,
                strokeWidth = 12.dp,
                lottieRes = R.raw.walker_man,
                isMoving = isMoving
            )
        }
    }
}

AI Agents

Needles to say yo can achieve this using any of the most popular coding tools. My choice was ChatGPT, but I bet you'd get equally good results with any other.

Result

video here

The whole code is in this repo.

The Onboarding

ViksaaSkool — Tue, 01 Feb 2022 00:40:52 +0000

A blog post I've been brewing for a while now.
The last half/two-thirds of 2021 in the company I work for, I've been an integral part of the onboаrding process of new hires- some filling void due to people leaving the team, some due to company growth. As an engineer it's natural to form some (strong?) opinions about a process you're observing, let alone being part of. I tried to keep it short and be as straight to the point as possible. So, here it goes:

If you're doing the onboаrding.

1. Documentation

Arguably the task a developer hates most - writing documentation. Close second: reading documentation.
In terms of value when it comes to onboarding people and returning back to, usually, very complex parts of the code - documentation is the crown jewels. Needless to say, if you/your company/your team don't document most the code, write code guidelines and diagrams in dedicated wiki and document custom processes in the development pipeline - you're not going to get far.
Robust organizations and sturdy developers do the hard things - they write and read documentation. Be one of them, lead the new hires by example.
Provide the documentation to the new hires and give them some time.

2. Pair up

This one maybe seem like a costly point in the short term, but it'll pay dividend in the long run. As I've said, having documentation and reading resources is essential, but having a real flesh-and-bone person, a colleague, walking a new hire trough the code base and processes, contributes to a seemingly onboarding and it cannot be (shouldn't be) substituted.
Make sure new hires have a go to person in the team, they can turn to in need in the first N months. Make sessions in which most competent person for a certain subject, part of the code base or process will onboard the new hire. That way you're making new personal bonds, while the knowledge transfer begins. Spread the sessions out as much as reasonably possible.
During the onboarding, if this is possible in your organization, make the new hires work alongside most experienced engineers in the team.

3. Track adaptation

This one falls to management - have an adaptation measurement on how well the new hires are fitting in. This one is important in order to recognize the early signs if something is getting out of hand or is not working out. The adaptation measurement can be anything that makes most sense to your organization - if you don't have one it can and will be yielded out by the onboarding process for you.

The week of the first successful PR.
The time spent on the first feature.
The complexity (story points?) of the bugs solved

Whatever makes most sense for you. Address problems as soon as they arise, don't assume, ask questions and make an effort to build rapport.

If you're being onboarded.

1. Do your homework

There always are going to be things in the field of your expertise, favorite technology, SDK/API that you don't know by heart. Even when you think you're on top of your game, tools, methods, libraries change - you can't feel on top every time - all the time, nobody does (not true, I know couple of people, but for the sake of the argument let's pretend). That being said, what you can, and should do when you're entering a new company is to do your homework - make sure you have as much domain knowledge as possible.
I work as an Android engineer, that develops apps that mostly revolve around Bluetooth, so if I get to onboard you - it will be handy if you know that part of the SDK/API. Even if you see that we have "our own way of doing things" in the onboarding process, it cannot be different than what the SDK/API intends to achieve.
If you don't have experience in a domain or part of the SDK, make sure you learn as much as possible, especially, before you make your first PR.

2. Proactive sweet spot

This one is hard to measure, but it comes with experience. If you are the beginning of your career it doesn't really matter, because you'll probably going to go on one or another extreme of the "I'm going to figure this one out on my own" - "Let's ask Bob or Lisa about this indentation" spectrum. Probably both, sometimes in the same company. Make sure when you ask questions you exhausted all the resources the Internet(s) have to offer. Double-check the dumbest possibilities, you might have overlooked something obvious. Be humble.

3. Get to know colleagues

Coding comes first, at the end of the day is just a job, BUT, you're going to spend most of the day at work - make sure to be as pleasant as it can be.
Be engaging and get to know your new colleagues, try to fit in - share your experiences and get involved as much as you feel comfortable to do so.
In my personal experience, the best, most engaging work the team that I've been part of has done is after get-togethers, team buildings and after work hangouts. Events nowadays and probably in the (near) future are going to be mostly remote, but we can give our best and make the most out of it.

The pandemic and hypochondria == dontgogleit.com

ViksaaSkool — Wed, 23 Sep 2020 08:21:41 +0000

So. Let's start with that title.

The pandemic a.k.a covid-19, coronavirus, rona, it's been all over the news, all kinds of timelines, everywhere, you read/hear details that you might not want to, a term we can all relate to.

Hypochondria or the new term - health anxiety - some of you might not be on board with this one and still clicked the post, out of curiosity, maybe. Are you overly aware of your body sensations? Do you check your symptoms and it's pretty easy to construct conspiracy theory about what terminal illness they're sign of?
I do.

To me and I presume to most other people with health anxiety, this means almost constant stress and decreased ability to concentrate and work (code). One thing I've known for a while is that the golden rule in these situations is NOT TO GOOGLE your symptoms, that doesn't mean that you should disregard your health, but if you have any suspicions, you should contact/visit medical professional instead of Dr.Google. In the absence of fully functioning health care system (especially if you live in the second or third world or your country is hard hit from the pandemic), this is not really possible (or considered risky).

And that's how we come to the third part of the title. I wanted to create a top notch, latest UI/UX implemented web page that ease the effects of this mix of health anxiety and pandemic mayhem. And that's how dontgogleit.com was born.

yes, cat gifs!

It's very intuitive and easy to use. You can even change themes and share the page on your social media portals!

Note: the domain with two o's would have costed me the same as buying this beauty, so I opted out and bought the cheaper version (of the domain).

Google play woes and the Android dev community

ViksaaSkool — Tue, 26 May 2020 08:39:00 +0000

Introduction

The best part about being a developer to me is the ability to create something from nothing (and share it with the world).
Mobile development has been (and still is?) one of the most interesting roads you can take having this thought in mind, which is why I've been working as an Android mobile developer for the past 7 years. In that time, like everything in nature, a lot of things have changed, evolved for the better or dead-ended somewhere on the mount improbable.

One thing that also evolved trough time, understandably so, are the Google Play Console Policies. Sarting off as very inviting and accommodating to becoming very strict, and yet in other parts very vague and open to interpretation.
With the app quantity growth, stricter rules are somewhat a guarantee for app quality a perspective I fully comprehend. Google has decided to enforce this by, in worst case scenario, terminating your developer account (and you as a developer) for good from their app publishing platform. Fair enough.

Observations/Opinions/Thoughts

I may be naive, but I think the vast majority of the developers would rather respect the rules than try to hack em if they know that the punishment for that behaviour is a career change. To top that, from a devs perspective, the main problem regarding publishing apps to Google Play Console is the automated system deciding on your app/account termination (as I said, worst case scenario) and the low probability of being able to contact human being with clarification on why's there a problem with your app submission (and be given a chance to correct it).

It seems that in this system the collateral damage are the developers that unintentionally have broken some of the rules.
This setting makes it especially hard for novice developers to publish "show off"/"practice" apps - not having enough experience (even though you can get banned for totally development unrelated reasons), chances are that you might miss something.
Seasoned Android dev enthusiasts may also be holding off app publishing, regardless if they do this as "side gig" or as a main source of income, a mistake that can result with account termination looks too costly.
Lastly, if there's no balance, this will put (puts?) strain on start ups to pursuit and channelize creative new ideas as an Android app, where this being an end product of the goal to tighten the leash on deceptive agents trying to exploit the users.

Research

r/androiddev on reddit with 143K subscribers is the main go-to place for the global Android community- covering all topics of the android dev lifecycle - from libraries, code, snippets, discussions and self-promotions to Google Play app/account problems (suspension/termination) related posts. I've been active member ever since I've started developing Android and just by daily scrolling through it seems that lately, especially in the last year[*] the amount of these Google Play related ("termination/suspension") posts have risen in numbers.

I want to analyze the relationship between the Google Play Console policies and its changes and the Android developer community. Do that in straightforward fashion: gather the data, put hypothesis in mind to the test, explore the data and see where it'll take me.

Using python and pushshift.io API I've gathered 10K r/androiddev posts per year in the 2015 to 2019 time interval and created a data set (which is public and you can access it on kaggle)

Data analysis:
⋅ filter out and create sub-sets with Google Play Related ("termination/suspension") posts - they usually contain at least one of the following words/phrases in this list: ["google play account", "suspension", "suspended", "terminated","termination", "ban", "banned", "app removed"]
⋅ normalize and structure data so data visualizations can be done
⋅ inspect the amount and popularity (karma) of these kind of posts (submissions)
⋅ check out the monthly post dispersion on per year basis
⋅ weigh-in Google play policy changes dates
Hypothesis:
⋅ Google Play Related ("termination/suspension") posts are on the rise
⋅ Google Play Related ("termination/suspension") posts flock right after some Google Play Policy change happens
⋅ Google Play Related ("termination/suspension") posts are at the top of the posts when sorted by karma

Results

The first place I went and the first question I wanted to answer is- are the Google Play Related ("termination/suspension") posts on the rise?
The answer: yes.

The data shows a decline in these kind of submissions on r/androiddev with the lowest point being 2017 with around 60 and then it start rising to 175 in 2019. With the basic premise proven right, just in terms of quantity I wanted to explore the relationship between Google Play Developer Policy Center updates and r/androiddev submission number fluctuations.

Here is the total amount of updates per year:

As it can be easily concluded there's no clear link between the number of updates with the spike or number of Google Play "termination/suspension" submissions on r/androiddev - 2017 had 6 changes but least number of subbmisions to the subreddit. What can be further explored is to cross-reference the months when the updates have happened and the number of posts. Here's that dispersion, in which should be noted - the months on x-axis marked in red rectangle have Google Play Developer Policy Center updates (source).

It's noticeable that more posts happen in a month with a policy change or the following period. To determine this further, the nature of the update must be inspected - which changes, theoretically yield more termination/suspension submissions and are they related. For example, in 2017 it can be observed that the biggest spike in submissions is in August. One possible route to pursue is to determine if the submissions are, let's say related to gambling apps, given the policy changes:

However, this will not be point of interest in this research as it requires more resources and time, but is not excluded as a possibility for part 2?

Another engaging matter of the research is to see how the community reacts to these submissions and how it values them - that can be seen trough karma (difference between upvotes and downvotes). Firstly, we get ambiguous results when the total karma is weighted against the karma that Google Play Related ("termination/suspension") posts got:

The picture is very different when top 10 submissions sorted by karma are matched against top 10 Google Play Related submissions:

As it can be seen, in 2019 the karma the community "gave" to the top 10 posts is only twice as much as the karma given to Google Play related posts. On the other hand, the karma given to these kind of posts is also increasing.

And finally, the percentage of Google Play related submissions in top 10 posts for the given year:

To put it simply, one out of the top 10 submissions on r/androiddev in 2018 and 2019 has some relation to app termination or suspension.

Discussion

The goal of this article is not to justify breaking of the polices or point fingers, rather than determine the status of the relationship between developers and their app publishing platform. The research is more centered on numbers rather than letters, meaning, the context of the submissions is not part of this research, something that can steer the conclusion in different direction.

What numbers show is that this is valid point for discussion and apparently is something developers experience and want to talk about. Further research should have a goal of determining the rightfulness of these submissions, as well as their resolution - something that looks like it might be hard to measure in automated fashion.

P.S. Let's finish off on a bright note:

Top 5 posts of r/androiddev per year

2015: 1 (karma: 615), 2 (karma: 466), 3 (karma: 416), 4 (karma: 408), 5 (karma: 355)
2016: 1 (karma: 1152), 2 (karma: 604), 3 (karma: 534), 4 (karma: 522), 5 (karma: 463)
2017: 1 (karma: 1146), 2 (karma: 1028), 3 (karma: 990), 4 (karma: 661), 5 (karma: 660)
2018: 1 (karma: 824), 2 (karma: 783), 3 (karma: 692), 4 (karma: 532), 5 (karma: 509)
2019: 1 (karma: 705), 2 (karma: 655), 3 (karma: 544), 4 (karma: 536), 5 (karma: 531)

*As of May-14-2020, these posts are not allowed on r/androiddev

Data gathering with python. An Example, get the tweets (part 2)

ViksaaSkool — Fri, 10 Apr 2020 12:08:53 +0000

In the previous post, the part one I've displayed how to automate part of the data gathering process where you know most of the constrains and you need to cut down the manual work of data entry. Namely, my challenge was that I wanted to get tweets from English (most resources for data analysis - sorry other languages 😩) speaking stand up comedians in predefined period.
I've managed to produce .csv file with name of the stand up comedian and respective twitter handle. Everything I need to gather(scrape) their tweets.

There's few ways one can achieve this:

Use Twitter API and preferred python library (there are a couple of good ones).
PRO: you're using the API - you know what data you'll get regardless of the UI/structural changes
CON(?): limited amount of options for free usage, that needs to be approved - there's a process where you need to apply and get the API Key as a result of a request for use processed successfully.
Use GetOldTweets3 (and variations of it)
PRO: easy to use for very little amount of data
CON: google "Too Many Requests"
Use nasty library (NASTY Advanced Search Tweet Yielder).
PRO: Easy to use, flexible
CON: I haven't came across one

Since I've tried all the approaches, I'll present you with the colab in which the one I think works the best: nasty

The result is .csv file with the format (it's this printed in rows):

After this the data needs to be cleaned, normalized and purified in order to be used for various purposes like sentiment analysis, topic modeling, labeling and so on.

Cheers.

Learn Python in 90 seconds!

ViksaaSkool — Wed, 08 Apr 2020 13:02:28 +0000

It's quarantine days and everybody is doing something useful. I'm no different than the super cool people out there: I made the best tutorial for learning python on the Internet(s). The best part? It takes you 90 seconds to complete and after it you'll be fluent in python!

Intrigued? Let's go then: pythonin90sec.com

Yes, it's a joke. Till next time.

Data gathering with python. An Example (part 1)

ViksaaSkool — Thu, 02 Apr 2020 09:09:47 +0000

Big data, data science, machine learning, AI, deep learning, python - to a marketing person catchy selling point, to a mathematician interesting real life implementation of the language of nature, to a software engineer tools to solving real life problems (and help people become even lazier).

Don't be taken off by the poetic start of this post, there will be code.

Myself and as I presume, many software engineers nowadays, want to get into data science, comprehend enough of the underlying processes and math so I/we can properly implement algorithms and approaches to data sets and utilize them in form of useful applications.
Where do you start when you try to get into data science (in my case: NLP(Natural language processing))?

The data.

I had this problem - I wanted to gather tweets form stand up comedians in order to do analysis. My weapon of choice: python and colab (Google's version of Jupiter notebooks)

Problems:

How to find the comedians?
How to find the comedians on twitter?
How to gather the tweet data (in separate post, coming soon)

Solution:

Wikipedia - find list of all English speaking comedians
Automated google search for twitter handles
Use TwitterAPI - a bit restrictive lately (or try tо scrape?)

The code:

Resulting file:

Now is up to step 3...
Easier approach: use the TwitterAPI via some of the many python SDKs (note: for which you need to apply and wait for a decision if you're going to get API key) - can't search the past
More challenging approach: scrape twitter (brace yourself for "To Many Requests" issue), something that I'll cover in separate post in near future.

[SPOILER ALERT]: use nasty!

#10YearChallenge

ViksaaSkool — Fri, 18 Jan 2019 16:35:30 +0000

2009 | wow I can code!

2019 | writing modular, maintainable code. using fancy language features, writing blog posts.

So, Kotlin, ha?

ViksaaSkool — Sun, 09 Dec 2018 23:08:23 +0000

This blog post (originally titled “Late for the Kotlin party”) has been in the file cabinet since spring and the “see the light of the optical cable” moment was postponed, because of, reasons. By now the original title has become outdated, but I kept most of the original structure and I think that the advices and notes in the post will work well for newcomers, so let it be.

You’re an Android developer and you’ve been slacking off learning Kotlin, staying in the comfort zone, maintaining Java code project(s), recently started Android and Java was overwhelming enough, or whatever the reason is - and now you’re figuring out that you’re kinda late? Well I guess so was I . This blog post is result of my Kotlin learning woes that I've structured in form of "Kotlin notes”/”point board”.
It is what it is, you have to do it if you want to stay relevant and even if your current position might not require that from you, things might change and you might end up in this position. Buckle up, I’ve made a crash transition course. There are a lot of layers to this, but it’ll get you started.

Let’s start with the resources, there are way too much resources and I’ll try to keep as tidy as possible:

Kotlinlang docs - I know this is not the advice to give in the age of “googling everything”, but try to memorize as much as possible – like you’re studying for exam, a lot of things will be new and they might not have context but with trying out stuff and looking at examples the pieces will fall together. You won’t be able to memorize everything and you’ll need to come back from time to time, but I’ve found this approach very helpful and having those “aha, so that’s what they’ve meant with that/so that’s how I use this-and-this-thing” moments To be noted, also: official Android documentation – as it comes to examples that matter you. You’ll come here when troubles arise just to have reality check that you’re not that smart and that component you thought was intuitive and you knew how it worked does not quite resemble the reality.
Blogs – dev.to/medium posts from enthusiast from the industry are probably the best source where you can learn new stuff – they are usually targeted and are result of some difficulty that was overcame by someone patient enough to derivate the effort into tutorial/github project/”copy – paste code”.
Books – there are couple books, but the one that I think cuts it – is "Kotlin for Android Developers - Learn Kotlin the easy way while developing an Android App" by Antonio Leiva and if you have the means I recommend you get your hands to it. Dependent on your level will be the level of how useful you’ll find it (ideally you’ll create the app along reading, or just read it and try to replicate some of the code and concepts into your own idea/s), still be open there are always chances to learn new stuff.
r/androiddev/ - stay up-to-date everything including Kotlin – read it once or twice a week. Or daily, with the coffee mug. Great community that can also help with some issues and point out for you other learning resources.
When you go trough the resources and get a bit knowledge on the matter you'd like to see examples and how the pros are doing it. This article points out 10 Android apps that are written in Kotlin and are open source on Github, I suggest you check them out a little bit latter, when you start coding in Kotlin and get stuck or look for ideas to solve something.

First thing you hear when Kotlin witness knocks on your door is that NullPointerException doesn’t exist anymore and your life will get easier. Yeah, you also need to learn a bunch of new stuff and there are A LOT of new stuff. I know, I know, like every good programming story starts, this one also starts with a lie - that it’ll take you just few days. Amm, no. It’s different from Java and no matter what they say, it takes time (effort) to get familiar with the new terms, paradigms and then to know when to apply{} them (needless to say, pun intended). Yes, you can read Kotlin code even if you never written one line.

Everything starts with Any. Here are the basics:

This doesn't look so bad right? Let's go with more complex subjects, remember those Utils classes you’ve been copy-pasting from project to project? Well, you don’t need to now, you can replace them with extensions for the most part or change the structure a bit. To be noted, some more interesting concepts like lambdas (that have been around), inline functions are introduced that will yield the wanted result - making modular, reusable code snippets and blocks, happen with less work. These concepts come along with a lot of baggage and there's a steep learning curve since some of the examples might look too abstract and then real life app usage might seem too complex and hard to understand. I'll just throw them out there, yet it'll take time and effort to be able to know and understand when to use them. Probably the easiest and most intuitive part of the code when you come across these concept is when you build your util classes or when you handle events and callbacks. Start from there and build from that.

Let’s dwell into something you’ll come across and use frequently – high-order functions that implement idiomatic patters – apply, let, also and run/with. The concept is introduced in the standard Kotlin library and they are meant to help the developer achieve more with writing less – a very rough, Java-resembling explanation of the functions is that they are “enhancement” of this.

This table sums it all up and how time passes and you get experience, it’ll become more and more apparent:

Yes, making decisions is hard:

On this subject, here’s a great blog post that you should read.

Another thing that's specific to Kotlin are Delegated properties, based on the delegation pattern, which by definition is an object-oriented design pattern that allows object composition to achieve the same code reuse as inheritance. The explanation in Android terms can be simplified as value assignment to property under certain conditions.Delegates can be standard from Kotlin and custom, defined by the developer. In the following gist, more details:

Regardless of the language, you should use generics and more importantly you need to know when and why to use them. By trying to make your code look fancy you might end up over-engineering the whole damn thing, but that's a general rule and subject out of the scope of this blog post. Some simple examples how generics are done in Kotlin:

One new thing that has been out there for a while, but now with Kotlin is introduced in Android are Coroutines. The main purpose of Couroutines is to tak over the async/background-running parts of the app and make them smoother and nicer. That's in theory. There are few resources on this and even though rock star part of the community has already started using them, it might be too early for you to implement these in more serious project. Here are the basics

You should take into account other subjects that are complex regardless of the language, but do have some specifics, like implementing patterns and when to use them. Architectures that are popular and have pretty detailed explanation and examples can be found here:

MVP (Vanilla MVP)
MVVM
some people like MVI, but I'd recommend you say no to MVI

Watch out when you implement Dagger. Things get funky and you need to use some of the things discussed in the gists above in order to make it work. The official coffee maker documentation is not very intuitive, so for more here and here (alternative: Koin, with caution).

Very popular Kotlin library that makes Android development easier - Anko. Suggestion - don't use it until you get grasp of things.

Last, but not least - testing - a bit different, but that is such a broad subject that will probably be touched upon in some other blog post in the near future.

tl;dr -> How is Kotlin different from Java:

New syntax, obviously - funky (and useful stuff)
No NullpointerException (by default)
String Literals
Companion objects
Delegates (lateinit, by lazy)
Lambdas (are everywhere)
let, apply, also, it, when, run - rough explanation: enhancements of "this."
Overriding properties
Data classes (no more getters and setters)
Sealed Classes
Inline classes
Extensions (say goodbye to ___Utils.class)
Inline functions
Function types
Functions with variable number of arguments (Varargs)
Operator overloading
Coroutines

To wrap it up on a Zen note, to self and whoever got to here by reading: you can’t use everything at once and you can’t know everything. Some things that are hot and all the cool kids are using them, are going to get extinct before you know it. Others are here to stay. In a sense everything in the industry is hype, things are fast changing (and evolving) and you should adopt to the changes fast. Only a fool can think that Kotlin is gonna disappear anytime soon, so all feelings aside, this is (and will be) the way to go when it comes to Android development.

P.S. This tutorial (in form of workshop) from Yelp's GitHub is just awesome!

Getting back on the horse

ViksaaSkool — Tue, 28 Aug 2018 21:29:43 +0000

We’re more than half way through 2018 and I’ve learned not to take things for granted. Very basic things like, walking and playing sports. Below, my left ankle

I was playing football (soccer) in early February and thought a tackle to save a goal would be smart thing to do – learnt the hard way, it wasn’t. At the moment of writing this blog post it’s been more than 6 months – doing daily activites feels like it never happened. I’ve started running, doing some light agility exercises and probably in 2 months I’ll be able to play football again (yeah, I have to get back on the field, otherwise I haven’t really beaten the injury have I?). For about 50 days I wasn’t able to walk and I was off work, I know – you code with your hands, the injury shouldn’t be a problem – well mentally it was really hard, after reading tons of horror stories about broken ankle, which the Internet is full of – I couldn’t concentrate. It was lightly reading some Kotlin related stuff, blogs, r/androiddev nothing too involved. Around 70 days with no coding.

The one other thing that I took for granted and was kinda taken away from me with this injury was coding form and coding enthusiasm.

The rule of thumb that I learned in physio sessions is that the time you’ll need to be walking normally again and do basic stuff with no problems equals the amount of time that you weren’t able to walk – I think this is somewhat applicable in the coding world. If you leave yourself away from IDEs for X amount of time you’ll need X amount of time to get back in the game. In my case 2 months of NO coding at all, really meant 2 months of hard work in the Android Studio and I still feel that I have some catching up to do. In this period, I’ve read this blog post that got me feeling uneasy about the situation. It’s a quality one, take the time to read it, plus there’s valuable comment section too.

Anyways, that’s not what this blog post is about. This is about how to feel good about coding and some practical steps towards it. Remember, coding (and IT in general) is a very rapidly moving field, just a little staling in keeping track of the industry pulse might have fierce consequences. So, here it is, if you ever find yourself in similar position for whatever reason, a short list of what nows:

1. Everything has a price.
Getting back on the horse will take something away from you and your current state. Panic, so you can organize. Make your amendments. You’ll have to give something away – most likely it’ll be social life and sleep. Nothing can substitute the hours you put in to learn new stuff, no one can do it for you. You’ll have to do your all-nighters on your own. Patience and dedication is key. In my case I chose to give away sleep, social life (weekend fun, not all of it) and TV shows.

2. Work on your own project.
Detail out an idea you want to work on make a plan, possibly open a trello board. Make rough, but realistic deadlines for it. Make a realistic schedule when you can work on the tasks, but be demanding. You need to make up for lost time for whatever the reason is – push yourself. If you’re not experienced or a lot of time has passed – find a project on github/android examples go through it and try to replicate it (with as little copy-pasting as possible and when you do that make sure you understand what are you copy-pasting). Take time to grasp the things you don’t understand, if you get stuck ask somebody that has more experience, just don’t auto-pilot and go the extra mile.

3. Get involved, geek out
At work, be more demanding of yourself– take tasks that you haven’t worked on before, implement features that you’re not that familiar with. Write unit tests. Put yourself in calculated risks and take more responsibility.
Get back into the community talks if you were away from that too. Most big tech hubs have weekly meetings for user groups, find one and join – people there are enthusiasts, sharing ideas, talking about problems helps. If that’s not an option, check out the Internets.

These are harder that might look on the first glance and it cannot be stressed enough, you must get your head right – discipline and dedication. It sounds like cheap motivational talk, but you have to give a 110% and ride the hamster wheel until you feel comfortable again. Then you can tone it down a notch.