It's a C+ at best. That's what Nilay Patel, editor-in-chief of The Verge, had to say about ChatGPT's writing ability about a year ago. I was surprised at first because I thought LLMs were great at writing—but then I realized he had spent over a decade writing and editing high-quality articles. It was just a passing comment in a larger conversation about the promise of the AI industry, but often, I find myself coming back to it. It’s helped me maintain a balanced mindset about AI tools and how I adopt them at work.
\n\n\nHappiness is reality minus expectations
\n
\n— Tom Magliozzi
Software tools, historically, have been extremely good at being reliable. Their deterministic nature has helped set appropriate expectations for the people using them. LLMs are not that. They are probabilistic at their core. So we need to find a way to tone down our expectations when using AI tools. Viewing AI as a fast and always available intern whose output is C+ at best helps me set reasonable expectations. Expectations that keep me cautious while not becoming frustrated when they get things wrong.
\n\n\nIf you never try, you'll never know what you're capable of.
\n
\n— John Barrow
I could be an expert in my domain. But there is a lot of day-to-day work where I could use some help. Modern software development (or many modern jobs, for that matter) requires us to understand and contribute in many adjacent domains. Now, I have an intern who, while not perfect, is more confident and potentially knowledgeable than me in those domains. That helps me cross some bridges I am hesitant to approach. It's still C+ at best, but many times, that's good enough. In a completely new area, C+ is a great start.
\n\n\nIf you want to build a great company, you have to surround yourself with A players
\n
\n— Steve Jobs
I am expected to do A+ work—especially in my core domain. I can't fully delegate it to a C+ intern and call it a day. If the intern ends up saving my time, I ought to use the saved time to make my work much better. Sometimes, the intern doesn't save any time—and that's OK. It's nothing new. Interns often take more time from you than they save.
\n\n\n'What's not going to change in the next 10 years?' is the more important question
\n
\n— Jeff Bezos
Nilay might grade the new models higher, and indeed, LLMs have improved significantly. But, the exact grade matters less than their true nature: usually good enough but rarely exceptional. That's still the case and likely going to be the case for as long as they are trained using the whole of human mediocrity. A little adjustment in mindset can get the best out of us with AI.
\n", "date_published": "2025-04-21T14:22:00Z" } , { "id": "https://okmanideep.me/nushell-after-8-months/", "url": "https://okmanideep.me/nushell-after-8-months/", "title": "Nushell, after 8 months", "content_html": "\n\n\n... Plain text is definitely simpler than tables. So maybe we are just moving complexity here. Or this is a very good abstraction and a lot of things improve. Time will tell.
\n
And the last 8 months have told me - Tables are a very good abstraction for CLI. No doubt. Possibly because they retain the fundamental nature of Values. In fact, tables are already present in unix shell, hiding in plain text. ps, ll, kubectl and many more programs have a tabular output. And to do anything with them, it's a lot more easier in nushell than in bash or similar shells.
I had my concerns initially - "Won't I face a lot of issues with all the unix programs, that just expect plain text and output plain text?". But it's barely been a problem. nushell's inbuilt commands and operators just take care of converting plain text to structured data and extract the necessary values to pipe them back into other programs.
Let's take an example. Get the first pod's name with the status Running in a kubernetes cluster and enter it's shell?
$ kubectl -n namespace get podsgets you a table like this
\nNAME READY STATUS RESTARTS AGE\nnamespace-86c7df9555-4n9cc 1/1 Running 0 2d2h\nnamespace-86c7df9555-65nks 1/1 Running 0 2d2h\nnamespace-86c7df9555-cdzll 1/1 Running 1 (35h ago) 2d1h\nnamespace-86c7df9555-dlpnx 1/1 Running 0 35h\nnamespace-86c7df9555-fnrgd 1/1 Running 0 2d2h\nnamespace-86c7df9555-lnx2v 1/1 Running 0 2d1h\nnamespace-86c7df9555-nmwrx 1/1 Running 0 2d2h\nnamespace-86c7df9555-xv45m 1/1 Running 0 35h\nThis is just plain text but pipe it into detect columns and we get an actual nushell table
$ kubectl -n namespace get pods | detect columns![](\"https://imgur.com/k5im8XR.png\")
\nNow we can filter the rows with where and get the first row with first
$ kubectl -n namespace get pods | detect columns | where { $it.STATUS == \"Running\" } | first | get NAMEWe can store this in a variable and access the shell with kubectl exec
$ let pod_id = kubectl -n namespace get pods | detect columns | where { $it.STATUS == \"Running\" } | first | get NAME
$ kubectl -n namespace exec -it $pod_id -- /bin/bashOr just put it in () brackets and use it directly
$ kubectl -n namespace exec -it (kubectl -n namespace get pods | detect columns | where { $it.STATUS == \"Running\" } | first | get NAME) -- /bin/bashWorking within nushell has been a lot like working with the programming languages that I am used to. It feels like I am in a REPL of one of those languages. Familiar and comfortable.
Lately I have been working with some csv files and what a delight it has been to work with them in nushell.
Colleague pings me saying "Here are the leads we want to add to the database - leads.csv".
\nI take a look at the file and there are some invalid user_ids in the file.
\nopen leads.csv | where { ($it.user_id | describe) != 'int' } | countI inform him - "Hey, we have 32 invalid user_ids in the leads.csv file. I will ignore them for now." and move on.
\nopen leads.csv | where { ($it.user_id | describe) == 'int' } | get user_id | str join ',' | pbcopy(Copies the user_ids to the clipboard)
\nI can probably do the same with awk and sed in bash. But this is a lot more simpler for me. Possibly because I work with object oriented languages a lot. And commands like where, first, take, skip are very familiar to me because all the languages have adopted these functional paradigms for operating with collections / streams.
By the way, if I want to convert that CSV to JSON?
\nopen leads.csv | to json | pbcopyReady to just paste it into a node REPL.
\nThis works with CSV, JSON, YAML, TOML, SQLite and many more formats. This came in handy to check which exact version of package is being used in a package-lock.json file a number of times.
open package-lock.json | get dependencies.ws.versionnumber of lines
\ncat inputs/day12.txt | lines | lengthnumber of characters per line
\ncat inputs/day12.text | lines | first | split chars | lengthWhile I was about to adopt a new shell that's not 1.0 yet, I was expecting to deal with some rough edges.
\n\n\n\nIt feels like a pre-honeymoon phase with nu. So there is a lot of adulation right now. It's likely that there are a lot of sour learnings to follow
\n
To be honest, I didn't have to deal with many issues. But there was one which took a bit of time to figure out.
\nfnm - fast node version manager, only offer setup instructions for bash, zsh, fish and powershell to add necessary changes to the shell profile for the right $PATH. For nushell, we have to use something like this
# fnm - node version manager
# https://dev.to/vaibhavdn/using-fnm-with-nushell-3kh1
load-env (/opt/homebrew/bin/fnm env --shell bash | lines | str replace 'export ' '' | str replace -a '\"' '' | split column = | rename name value | where name != \"FNM_ARCH\" and name != \"PATH\" | reduce -f {} {|it, acc| $acc | upsert $it.name $it.value })
$env.PATH = ($env.PATH | prepend $\"($env.FNM_MULTISHELL_PATH)/bin\")Essentially fake the shell, get the necessary changes and apply them to the nushell environment.
Some extra work to setup programs that output configuration for bash / zsh etc. And a few copy pasta for setting up some completions.
\nThat's about it. After I have setup nushell in my system and added it to my dotfiles, it's been a smooth ride across both Windows and MacOS. I have been using nushell as my primary shell for the last 8 months and I don't see myself going back to bash or zsh or powershell.
From the moment I saw the intro video I found it very appealing. It takes the best of bash(in unix) and powershell. I will assume you could totally relate to the bash part of that sentence.
powershell?I like the structural data flow in powershell. Since powershell commands aren't as well named for casual and quick scripting, it doesn't look good. But my OOP brain that could not master regex or awk in a decade was attracted to the named, associative data structures moving through the command pipeline.
I remember the first time I was trying to find the last modified file in a directory in a terminal running bash. I knew ls and I knew sort. I was totally in awe of the unix philosophy - individual programs doing only one thing and doing it well, composing different programs to solve complicated problems. So I tried
$ ls | sort![\"ls](\"https://i.imgur.com/i0FEqKZ.jpg\")
\n🤔: Oh! ls only outputs names. So I should use ll in this case
$ ll | sort![](\"https://i.imgur.com/ew8uvmA.jpg\")
\n🤔: But how do I tell the sort command which property to use for sorting? Does it use size? Does it use the file name?
I was obviously missing something. I found the answer with a quick Google. There is a -t flag on ls
So ls also does sorting. That's... not... simple... right?
You get the point. So let's see how it works in powershell
$ Get-ChildItem | Sort-Object -Property LastWriteTime -DescendingI told you it doesn't look good. Ok, you can make it slightly better with the built in aliases and lowercase letters, but the most good looking you can get is
\n$ ls | sort-object -property lastwritetime -descending![\"last](\"https://i.imgur.com/xvMFXrr.jpg\")
\nUnlike plain strings in bash, in powershell we deal with structured data. ls outputs a table with columns - Mode, LastWriteTime, Length and Name. Which I can use further in the command pipeline to tell the sort-object command to sort the table using lastwritetime property
It doesn't look like the most convenient to type but I can understand how this works and use it in more places for solving more problems than the -t flag on ls.
This is how you do the same thing in nu
$ ls | sort-by -r modifiedJust like powershell, ls outputs a table
![\"ls](\"https://i.imgur.com/tZEXjpl.jpg\")
\nBut the names are much better. They bring the comfort and fun that was missing in using powershell. As I said, best of both worlds. Nushell's homepage has an even better example.
![\"ls](\"https://www.nushell.sh/frontpage/ls-example.png\")
\npowershell was very slow to start. I guess it's mostly because of the plugins I am importing in my profile but it takes 1500ms+ to initiliaze after a restart, and ~1000ms for every new tab I open in my terminal.
![\"powershell](\"https://i.imgur.com/oo37EzL.jpg\")
\nThis is after I have spent some time profiling and optimizing. I removed a few plugins that were good to have but not must haves.
\nI have been living with this for well over an year. Why you ask? Because I hate lock in. I remember watching all the sensible features Microsoft was bringing to Windows that were aimed directly at developers and wanting to give it a try. And then I realized I actually can't, with my current workflow. It's a long boring journey that we can talk later. But powershell was the only cross platform shell I could find to have a consistent workflow between my PC at home and my office Mac.
And nu startup in less than 100ms after I have configured it to my liking with largely same behaviors.
![\"nushell](\"https://i.imgur.com/40pcOjZ.jpg\")
\nBesides startup, the speed while usage isn't much different. It's barely noticeable and I won't be surprised if powershell beats nu in a few cases. But being ready to type as soon as I press the short cut for new tab, feels very nice.
I also have vi mode on the command line. I don't have to Google "move the cursor back word by word in command line" anymore.
I am still a noob in bash and powershell. And I am a mega noob in nushell. It feels like a pre-honeymoon phase with nu. So there is a lot of adulation right now. It's likely that there are a lot of sour learnings to follow. Plain text is definitely simpler than tables. So maybe we are just moving complexity here. Or this is a very good abstraction and a lot of things improve. Time will tell.
If you are as intrigued by nushell as I am and want to give it a spin, I will warn you about one key thing - The language that is used for configuration and scripting - nu is not locked yet. They intend to evolve it and mercilessly break things until 1.0. You've been warned.
Dart 3 🎯 is here! And it brings very useful features like sealed classes, pattern matching and many more.
It also ends the support for --no-sound-null-safety.
Which means to adopt it in any codebase, every single file should be null safe.
\nLike us at Praja, if you have started writing your Flutter app more than a couple of years ago, you would have started slowly migrating your codebase to sound null safety. Some of you would have completed it. If you are one of them I would like to here about your experience and learn what helped and what didn't.
\nIf you are still going through this transition, I hope this helps you. Here's how we have approached it.
\nOfficial Dart Guide for migrating to null safety
\nSkip this step if you have already done it.
\n// @dart = 2.9 to the starting of every dart file in your project and manually convert your main.dartThe following script can help you out here
\n#!/usr/bin/env ruby
directory = \"/lib\"
# Navigate to the directory
Dir.chdir(directory)
# Loop through each .dart file in the directory
Dir.glob(\"**/*.dart\").each do |file|
# Check if the file is a regular file
if File.file?(file)
# Prepend \"// @dart=2.9\" to the file
content = File.read(file)
File.open(file, \"w\") do |f|
f.write(\"// @dart=2.9\\n#{content}\")
end
puts \"Added // @dart=2.9 to #{file}\"
end
endWith this you can start using flutter run --no-sound-null-safety and run your app as always
Since this doesn't immediately impact the product, it's not going to be worth it to migrate all the files as a single task / project. We want to do this gradually over a few months. For that, we'd like some regular nudges to everyone in the team to slowly convert files they are touching.
\nA PR check like this can help out in a big way
\nname: Dart Null Safety Validation
on: [pull_request]
env:
GITHUB_BASE_REF: $
jobs:
validate:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Validate Dart files
shell: bash
run: |
# Fetch the base branch for diffing
git fetch origin $GITHUB_BASE_REF:$GITHUB_BASE_REF
n_files=$((grep -r -H --include \\*.dart \"// @dart = 2.9\" $(git diff --name-only $GITHUB_BASE_REF --diff-filter=AMR) || true) | wc -l)
if [ $n_files -ne 0 ]; then
echo \"Dart Files that changed, but still contain 2.9 dart version:\"
grep -r -H --include \\*.dart \"// @dart = 2.9\" $(git diff --name-only $GITHUB_BASE_REF --diff-filter=AMR)
echo \"\\n\"
echo \"Please convert the above files to project dart version\"
exit 1
fi
This validates that all .dart files added/modified in a PR are null safe.
Based on your team, you can choose to make this an optional or a required check. We chose to have it as optional and it worked out for us.
\nWith just this, over a couple of months, we converted over half the codebase to null safety!
\nThere are bound to be some files which are not touched at all and are lying there, which stop your from adopting full sound null safety. The PR check is not going to help here.
\nA small script that can tell you how many files are left to convert and what are few low hanging fruits helps quite a bit
\n![](\"https://okmanideep.me/img/null-safe-report-usage.png\")
\n# frozen_string_literal: true
# Usage:
# From the root of this project
# $ ruby scripts/null_safe_report.rb ./lib
require 'find'
# This class is used to sort the files by line count
class FileToConvert
def initialize(file_name, line_count)
@file_name = file_name
@line_count = line_count
end
attr_reader :line_count
def to_s
\"#{@file_name}: #{@line_count} lines\"
end
end
path = ARGV[0]
file_count = 0
files_to_convert = []
Dir.glob(\"#{path}/**/*.dart\") do |file_name|
file_count += 1
first_line = File.open(file_name, &:readline)
is_non_null_safe = first_line.start_with?('// @dart = 2.9')
files_to_convert << FileToConvert.new(file_name, File.foreach(file_name).count) if is_non_null_safe
end
files_to_convert.sort_by!(&:line_count)
puts \"Null safe percent: #{((file_count - files_to_convert.count).to_f / file_count.to_f * 100).round(2)}%\"
puts \"Number of files left to convert: #{files_to_convert.count}\"
puts ''
puts '10 Smallest files left to convert:'
files_to_convert[0..9].each do |file|
puts file
endYou likely have a few huge files that no one wants to touch. Likely some God object definitions. There is no shortcut here. We have to approach it like some good old tech debt and buy some time to replace these.
\nWe are yet to make this final push. Will update this article if we have any learnings.
\n", "date_published": "2023-05-12T17:00:00Z" } , { "id": "https://okmanideep.me/understanding-composition-and-side-effects/", "url": "https://okmanideep.me/understanding-composition-and-side-effects/", "title": "Understanding Composition and Side Effects", "content_html": "\nJetpack Compose is a Declarative UI Framework that allows us to define UI, state and side effects by declaring functions. A lot of them. Named and anonymous (lambdas). We will try and understand when does the framework invoke the functions we are declaring.
\nSome of those functions we declare are Side Effects. Specifically we are going to look at LaunchedEffect, SideEffect and DisposableEffect
They look like this in the code
\nLaunchedEffect(/*key(s)*/) {
/* effect that we are declaring as a lambda */
}When the above code is run, LaunchedEffect the function runs and registers the lambda we passed, to run it when it needs to be run. Well when exactly? We should get an idea very soon.
Let's dive in.
\nA @Composable which sets up a bunch of logs inside Side Effects - DisposableEffect, SideEffect and LaunchedEffect
@Composable
fun Effects(
logTag: String,
key: Any = logTag,
) {
val tag = logTag.padEnd(25)
log(\"$tag - Registering Effects\")
LaunchedEffect(key) {
log(\"$tag - LaunchedEffect\")
}
DisposableEffect(key) {
log(\"$tag - DisposableEffect\")
onDispose {
log(\"$tag - onDispose\")
}
}
SideEffect {
log(\"$tag - SideEffect\")
}
}And a TrafficLight that shows an emoji in Text. Also uses the Effects we defined above for logging
@Composable
fun TrafficLight(
lightEmoji: String,
modifier: Modifier = Modifier
) {
Text(lightEmoji, fontSize = 120.sp, modifier = modifier)
Effects(\"TrafficLight($lightEmoji)\")
}We are going to start by adding and removing this TrafficLight on touch as shown below
@Composable
fun TouchAndGo() {
var isVisible by remember { mutableStateOf(false) }
Box(
contentAlignment = Alignment.Center,
modifier = Modifier
.fillMaxSize()
.clickable {
log(\"---Click---------------------\")
isVisible = !isVisible
},
) {
if (isVisible) {
TrafficLight(lightEmoji = \"🟢\")
}
}
}Initially we show nothing. On click, we show the green light 🟢.
\n\nTogether, this is what we have got
\n@Composable
fun TouchAndGo() {
var isVisible by remember { mutableStateOf(false) }
Box(
contentAlignment = Alignment.Center,
modifier = Modifier
.fillMaxSize()
.clickable {
log(\"---Click---------------------\")
isVisible = !isVisible
},
) {
if (isVisible) {
TrafficLight(lightEmoji = \"🟢\")
}
}
}
@Composable
fun TrafficLight(
lightEmoji: String,
modifier: Modifier = Modifier
) {
Text(lightEmoji, fontSize = 120.sp, modifier = modifier)
Effects(\"TrafficLight($lightEmoji)\")
}
@Composable
fun Effects(
logTag: String,
key: Any = logTag,
) {
val tag = logTag.padEnd(25)
log(\"$tag - Registering Effects\")
LaunchedEffect(key) {
log(\"$tag - LaunchedEffect\")
}
DisposableEffect(key) {
log(\"$tag - DisposableEffect\")
onDispose {
log(\"$tag - onDispose\")
}
}
SideEffect {
log(\"$tag - SideEffect\")
}
}Let's have a look at the logs
\n---Click---------------------\nTrafficLight(🟢) - Registering Effects\nTrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - LaunchedEffect\n---Click---------------------\nTrafficLight(🟢) - onDispose\nWhen a Composable enters composition:
@Composable function runs firstDisposableEffect, the SideEffect and the LaunchedEffect in that orderWhen a Composable exits composition:
onDispose of the corresponding DisposableEffect runsLet's make it slightly more interesting. Let's add Effects above and below the TrafficLight
@Composable
fun TouchAndGo() {
var isVisible by remember { mutableStateOf(false) }
Box(
/*...*/
) {
if (isVisible) {
+ Effects(\"Pre - TrafficLight(🟢)\")
TrafficLight(lightEmoji = \"🟢\")
+ Effects(\"Post - TrafficLight(🟢)\")
}
}
}So what do we have on the logs now?
\n---Click---------------------\nPre - TrafficLight(🟢) - Registering Effects\nTrafficLight(🟢) - Registering Effects\nPost - TrafficLight(🟢) - Registering Effects\nPre - TrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - DisposableEffect\nPost - TrafficLight(🟢) - DisposableEffect\nPre - TrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - SideEffect\nPost - TrafficLight(🟢) - SideEffect\nPre - TrafficLight(🟢) - LaunchedEffect\nTrafficLight(🟢) - LaunchedEffect\nPost - TrafficLight(🟢) - LaunchedEffect\n---Click---------------------\nPost - TrafficLight(🟢) - onDispose\nTrafficLight(🟢) - onDispose\nPre - TrafficLight(🟢) - onDispose\nOn Entering Composition:
\nDisposableEffects run first, followed by SideEffects, followed by LaunchedEffectOn Exiting Composition:
\nDisposableEffects are disposed in the reverse order they are declared / registered. Last In First Out - LIFO. Like a stack!Toggle between 🟢 and 🔴 on click
\n@Composable
fun StopAndGo() {
var go by remember { mutableStateOf(true) }
Box(
contentAlignment = Alignment.Center,
modifier = Modifier
.fillMaxSize()
.clickable {
log(\"---Click---------------------\")
go = !go
},
) {
val light = if (go) \"🟢\" else \"🔴\"
TrafficLight(lightEmoji = light)
}
}TrafficLight(🟢) - Registering Effects\nTrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - LaunchedEffect\n---Click---------------------\nTrafficLight(🔴) - Registering Effects\nTrafficLight(🟢) - onDispose\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\nDisposableEffects are registered before the outgoing DisposableEffects are disposedDisposableEffects are run after the outgoing DisposableEffects are disposedOne might have expected this, because compose runtime figures out what are incoming and what are outgoing only after it runs / re-runs our Composable functions based on the new State.
Nevertheless, this is an important aspect to keep in mind. Since this makes it safe for two Composables that are never in composition together, to acquire/release to the same resource in their DisposableEffects.
More often than not, we animate our changes. Let's look at the order of execution when we add animation to the above example
\n @Composable
fun StopFadeGo() {
var go by remember { mutableStateOf(true) }
Box(
contentAlignment = Alignment.Center,
modifier = Modifier
.fillMaxSize()
.clickable {
log(\"---Click---------------------\")
go = !go
},
) {
val light = if (go) \"🟢\" else \"🔴\"
+ Crossfade(targetState = light) {
+ TrafficLight(lightEmoji = it)
+ }
}
}TrafficLight(🟢) - Registering Effects\nTrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - LaunchedEffect\n---Click---------------------\nTrafficLight(🔴) - Registering Effects\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\nTrafficLight(🟢) - onDispose\nWhen animated, the outgoing DisposableEffects are disposed only after the animation is complete
Might feel obvious in hindsight. But it is important to keep in mind that since the incoming DisposableEffect runs before the outgoing disposes. This basically doesn't allow those Composables to acquire/attach-to the same resource.
🔴 Ready -> 🔴 Set -> 🟢 Go on click
\n@Composable
fun ReadySetGo() {
var count by remember { mutableStateOf(1) }
Box(
contentAlignment = Alignment.Center,
modifier = Modifier
.fillMaxSize()
.clickable {
log(\"---Click---------------------\")
count++
},
) {
val step = count % 3
val light = if (step == 0) \"🟢\" else \"🔴\"
val message = when (step) {
1 -> \"Ready\"
2 -> \"Set\"
0 -> \"GO!\"
else -> \"Uh Oh!\"
}
Column(horizontalAlignment = Alignment.CenterHorizontally) {
TrafficLight(lightEmoji = light)
Spacer(modifier = Modifier.height(8.dp))
Text(message, fontSize = 36.sp)
}
}
}TrafficLight(🔴) - Registering Effects\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\n---Click---------------------\n---Click---------------------\nTrafficLight(🟢) - Registering Effects\nTrafficLight(🔴) - onDispose\nTrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - LaunchedEffect\n\n\nNote that for both "Ready" and "Set" states, the light is 🔴
\n
Composition and Effects are skipped when the inputs don't change!
\nJust like the documentation says. But what does "inputs not changing" really mean? Let's find out.
\nInstead of passing in a String, let's create our own class
private class Light(val emoji: String)Update the TrafficLight and ReadySetGo to use Light instead of a String
@Composable
fun ReadySetGoClass() {
var count by remember { mutableStateOf(1) }
Box(
contentAlignment = Alignment.Center,
modifier = Modifier
.fillMaxSize()
.clickable {
log(\"---Click---------------------\")
count++
},
) {
val step = count % 3
+ val light = if (step == 0) Light(\"🟢\") else Light(\"🔴\")
val message = when (step) {
1 -> \"Ready\"
2 -> \"Set\"
0 -> \"GO!\"
else -> \"Uh Oh!\"
}
Column(horizontalAlignment = Alignment.CenterHorizontally) {
+ TrafficLight(light)
Spacer(modifier = Modifier.height(8.dp))
Text(message, fontSize = 36.sp)
}
}
}
@Composable
private fun TrafficLight(
+ light: Light,
modifier: Modifier = Modifier
) {
+ val lightEmoji = light.emoji
Text(lightEmoji, fontSize = 120.sp, modifier = modifier)
+ Effects(\"TrafficLight($lightEmoji)\", key = light)
}Here are the logs after the change
\nTrafficLight(🔴) - Registering Effects\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\n---Click---------------------\nTrafficLight(🔴) - Registering Effects\nTrafficLight(🔴) - onDispose\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\n---Click---------------------\nTrafficLight(🟢) - Registering Effects\nTrafficLight(🔴) - onDispose\nTrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - LaunchedEffect\nWell what happened there!
\nOur Light doesn't implement .equals(). The default implementation returns true only if they are the same instances. But we are creating a new instance every time. So compose runtime sees these as different inputs.
Let's add a log to equals()
private class Light(val emoji: String) {
override fun equals(other: Any?): Boolean {
if (other is Light) {
+ val result = super.equals(other)
+ log(\"$emoji.equals(${other.emoji}) = $result\")
return result
}
return super.equals(other)
}
}Haven't changed the implementation yet. Just added a log.
\nThe same logs as above but with equals()
TrafficLight(🔴) - Registering Effects\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\n---Click---------------------\n🔴.equals(🔴) = false\nTrafficLight(🔴) - Registering Effects\n🔴.equals(🔴) = false\n🔴.equals(🔴) = false\nTrafficLight(🔴) - onDispose\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\n---Click---------------------\n🔴.equals(🟢) = false\nTrafficLight(🟢) - Registering Effects\n🔴.equals(🟢) = false\n🔴.equals(🟢) = false\nTrafficLight(🔴) - onDispose\nTrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - LaunchedEffect\nSo compose runtime compared the inputs. It observed that they are different (.equals() returned false), so ran the composable with the new input. It then compared the inputs again, to see if it has to run the DisposableEffect and the LaunchedEffect and ran them again because it received false.
\n\nAfter all
\nDisposableEffectandLaunchedEffectareComposablefunctions themselves
Let's implement equals()
private class Light(val emoji: String) {
override fun equals(other: Any?): Boolean {
if (other is Light) {
+ val result = emoji == other.emoji
log(\"$emoji.equals(${other.emoji}) = $result\")
return result
}
return super.equals(other)
}
}TrafficLight(🔴) - Registering Effects\nTrafficLight(🔴) - DisposableEffect\nTrafficLight(🔴) - SideEffect\nTrafficLight(🔴) - LaunchedEffect\n---Click---------------------\n🔴.equals(🔴) = true\n---Click---------------------\n🔴.equals(🟢) = false\nTrafficLight(🟢) - Registering Effects\n🔴.equals(🟢) = false\n🔴.equals(🟢) = false\nTrafficLight(🔴) - onDispose\nTrafficLight(🟢) - DisposableEffect\nTrafficLight(🟢) - SideEffect\nTrafficLight(🟢) - LaunchedEffect\nBack to normal.
\nLet's summarize all the insights
\n➡️ On Entering Composition:
\nComposable function runs firstDisposableEffects run first, followed by SideEffects, followed by LaunchedEffect⬅️ On Exiting Composition:
\nDisposableEffects are disposed in the reverse order they are declared / registered. Last In First Out - LIFO. Like a stack!🔀 When a composable is being replaced with another or recomposed with the new state:
\nDisposableEffects are registered before the outgoing DisposableEffects are disposedDisposableEffects are run after the outgoing DisposableEffects are disposed💫 When animated, the outgoing DisposableEffects are disposed only after the animation is complete.
🚫 Composition and Effects are skipped when the inputs don't change. Inputs are compared using their equals() method
Google's approach in this google samples repo seems to be tackling it very well. They actually do it across multiple projects but it applies for multiple modules as well. If you just have one module, don't bother doing this right now, but remember to do it when you decide to extract a module out.
\nOur main objectives are to
\nDeclare your dependencies and versions at the root of the project.
\n$PROJECT_ROOT/dependencies.gradle
ext.versions = [:]
def versions = [:]
versions.support_lib = '26.0.2'
versions.gson = '2.8.0'
ext.versions = versions
ext.deps = [:]
def deps = [:]
def support_lib = [:]
support_lib.app_compat = \"com.android.support:appcompat-v7:$versions.support_lib\"
support_lib.recycler_view = \"com.android.support:recyclerview-v7:$versions.support_lib\"
deps.support_lib = support_lib
deps.gson = \"com.google.code.gson:gson:$versions.gson\"
ext.deps = depsAttaching versions and deps to extra user properties ext will allow you to access those variables all across the project
Import the definitions at the top of root project's buildScript block
$PROJECT_ROOT/build.gradle
buildScript {
apply from: 'dependencies.gradle'
//left out for brevity...
}Declare your module dependencies using the variables defined
\n$PROJECT_ROOT/my-module/build.gradle
//left for brevity...
dependecies {
implementation deps.support_lib.app_compat
implementation deps.support_lib.recycler_view
implementation deps.gson
}All we have done is remove duplication by reusing the version and dependency declarations done at one single place. Since all modules point to the same declaration, they all are in sync. And since there is only one declaration per dependency in the project, it is easy to find and update that one dependency.
\nOnce you declare the variables, IntelliJ doesn't auto complete or suggest them else where when you are editing the gradle files. So make sure your variable name usages are proper and easily debuggable. That is intension behind using camel case here(YMMV).
\nThe error messages are not specific enough to figure out which variable name of dependency path you messed up. You can go ahead and define all the variables at once but add/use them one by one and sync your gradle file after each step to avoid frustrating debugging sessions.
\nWhat do you think of this approach? Is there a better way? I am actually curious how this changes when we use kotlin to write gradle files. Let me know your feedback.
\n", "date_published": "2017-11-02T00:20:00Z" } , { "id": "https://okmanideep.me/improve-your-android-build-times/", "url": "https://okmanideep.me/improve-your-android-build-times/", "title": "Improve your Android build times", "content_html": "If you have the time to watch the video, go ahead. Madis Pink goes over each optimisation you can do very carefully and how you can profile the gradle build process to identify the bottlenecks of your builds. If not, go ahead do the changes mentioned below, which will take less than two minutes and enjoy a much smaller build times.
\n\nIt doesn't matter your app is over the 65K method limit or not, enabling multiDex and having product flavors like this help a lot.
\nproductFlavors {
dev {
multiDexEnabled true
minSdkVersion 21
}
prod {
multiDexEnabled true
minSdkVersion 15
}
}And also keep in mind that Instant Run has some overhead on the dex method count in your debug builds, which might just make your method count go over the limit.
\nOn my machine for my project\n./gradlew :app:assembleProdDebug takes 55.623s and ./gradlew :app:assembleDevDebug takes 12.41s!
So yeah. Do it.
\nUsing a daemon essentially means, gradle keeps a JVM and gradle instance running after the first build and reuses the same for subsequent builds. Android Studio already uses a daemon for every build that is triggered from the IDE, but this is very useful for builds triggered from the command line.
\nDry Run without daemon
\n./gradlew :app:assembleDebug --dry-runOutput:
\nBUILD SUCCESSFUL\n\nTotal time: 11.657 secs\n\nThis build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.10/userguide/gradle_daemon.html\nIn your ~/.gradle/gradle.properties
org.gradle.daemon=true\nDry Run output after enabling daemon
\nBUILD SUCCESSFUL\n\nTotal time: 1.757 secs\nThe gradle team is constantly optimising the build performance and it is wise to be using the latest version for the best performance. Here is how you change it
\nIn <Project Root>/gradle/wrapper/
\nEdit gradle-wrapper.properties and upgrade gradle distributionUrl to the latest.
\n\nThe difference will be substantially good if you are upgrading from or below
\n2.4
Groovy, being a dynamic language, can really benifit from the invoke dynamic instruction in Java 7 and above. So using JDK7 or JDK8 will certainly be helpful.
Cmd+Shift+A or Ctrl+Shift+A, type Project Structure and change JDK Location to JDK 8 locationIf you have modules that are standalone, you can improve the build time a bit by enabling parallel execution.
\nIn your ./gradle/gradle.properties or <Project Root>/gradle.properties, add this line
org.gradle.parallel=true\nUse definite version numbers for your dependencies in your gradle
\n//Do NOT do this
compile 'com.google.code.gson:gson:2.+'
//Do this instead
compile 'com.google.code.gson:gson:2.3'This avoids the problem of gradle always making a network request to check for the latest version of the dependency
\nYou can find snippets like this on stack overflow that aim to make versioning easier for you
\ndef cmd = 'git rev-list HEAD --first-parent --count'
def gitVersion = cmd.execute().text.trim().toInteger()
android {
defaultConfig {
versionCode gitVersion
}
}The problem with this code is - gradle needs to count the number of commits for every build. For a large repo which has around 20000 commits, it takes around half a second to just count the number of commits.
After these optimisations your first build might take the same amount of time, but trust me your subsequent builds will be much faster overall.
\nAlso there is one more very important optimisation you can do
\nPlease do.
\n", "date_published": "2016-04-05T20:10:00Z" } , { "id": "https://okmanideep.me/rxconfusions-part-1-map-and-flatmap/", "url": "https://okmanideep.me/rxconfusions-part-1-map-and-flatmap/", "title": "RxConfusions - Part 1 : Map and FlatMap", "content_html": "If you don't know what RxJava is or you aren't comfortable with the terms Observable, Observer, Operator and Subscriber, I suggest you have a look at Grokking RxJava series by Dan Lew.
If you have surfed through some RxJava content on the web, you should have come accross the map() operator. It is exactly what you think it is. But you might have seen people using the flatMap() operator in similar senarios which might have confused you a bit. Let's use them both in a small example and observe the effects of these operators.
Let's use this simple Observer for logging
public void onCompleted() {
System.out.println(\"onCompleted\");
}
public void onError(Throwable e) {
System.out.printf(\"onError: %s\\n\", e);
}
public void onNext(String s) {
System.out.printf(\"onNext: %s\\n\", s);
}public static void main(String[] args) {
Printer printer = new Printer();
String[] names = new String[] {\"John\", \"Samuel\", \"Micheal\", \"Tom\"};
printer.printTitlesUsingMap(names);
}
private void printTitlesUsingMap(String[] names) {
Observable.from(names)
.map(Printer::getTitle)
.subscribe(this);
}
private static String getTitle(String name) {
return String.format(\"%s - %d\", name, name.length());
}Output :
\nonNext: John - 4\nonNext: Micheal - 7\nonNext: Tom - 3\nonNext: Samuel - 6\nonCompleted\nLets make it a little interesting
\n private static String getTitle(String name) throws IllegalArgumentException{
+ if(\"Micheal\".equals(name)) {
+ throw new IllegalArgumentException(\"Too many Micheals\");
+ }
return String.format(\"%s - %d\", name, name.length());
}Output :
\nonNext: John - 4\nonNext: Samuel - 6\nonError: java.lang.IllegalArgumentException: Too many Micheals\nEven though there are too many Micheals, you don't want to stop printing once a Micheal arrives. You might be thinking lets use filter() to filter out Micheal but let us assume the printer doesn't know when getTitle() fails. Operators like map() can't change the flow items, they just modify the items which are emitted. This is when operators like flatMap() come in handly
private void printTitlesUsingFlatMap(String[] names) {
Observable.from(names)
.flatMap(Printer::getTitleObservable)
.subscribe(this);
}
private static Observable<String> getTitleObservable(String name) {
return Observable.create(subscriber -> {
if(!subscriber.isUnsubscribed()) {
+ try {
+ subscriber.onNext(getTitle(name));
+ } catch (IllegalArgumentException e) {
+ //do nothing
+ }
+ subscriber.onCompleted();
}
});
}Notice that we are calling subscriber.onComplete() for every name. Guess the output... guessed it? Now have a look
\nOutput :
onNext: John - 4\nonNext: Samuel - 6\nonNext: Tom - 3\nonCompleted\nIs that what you expected? Probably not. Now have a look at what happens if don't call subscriber.onComplete() when there is an exception.
return Observable.create(subscriber -> {
if(!subscriber.isUnsubscribed()) {
try {
subscriber.onNext(getTitle(name));
+ subscriber.onCompleted();
} catch (IllegalArgumentException e) {
//do nothing
}
}
});Make a guess before you look at the output.
\nonNext: John - 4\nonNext: Samuel - 6\nonNext: Tom - 3\nNo onComplete() at all.
\nNow make a guess who is the subscriber to our getTitleObservable() function.
\n\nThe
\nflatMap()operator is our subscriber
If you are thiking - 'Wait, flatMap() is an Operator not a Subscriber', you should watch Demistifying RxJava Subscribers by Jake Wharton. Basically, everything is a subscriber.
FlatMap collects all the observables returned for each item in the stream and emits all the items emitted by those observables. Simply put, it is a merge of all observables returned by your mapping function.\nIt calls onComplete() only when all the observables are completed.
In this example getTitleObservale("Micheal") wasn't completed. So FlatMap is waiting for it to complete(Yes, it is in the memory).
Visualise what happened in the above example. Now think about the map() operator. If you feel like - 'They are two very different operators', then I have done my job. If you don't, try confusing me as well.
I am no expert in this topic. Just sharing as I learn. Please drop me a tweet or a comment if I got anything wrong. And share it to people who you think will find this useful.
\nArtem Zinnatullin's post suggests a better way to for our getTitleObservable().
\nreturn Observable.fromCallable(() -> getTitle(name));By using this method, you don't need to worry about calling the right functions to the subscriber. Thanks to pakoito for pointing that out.
\n", "date_published": "2015-12-01T20:10:00Z" } , { "id": "https://okmanideep.me/clean-way-to-define-support-library-dependencies/", "url": "https://okmanideep.me/clean-way-to-define-support-library-dependencies/", "title": "Clean way to define support library dependencies", "content_html": "As the support library started getting bigger with more tools in it, the team at google have suggested developers to pick and choose the individual pieces of the library in their dependencies. More recently our build.gradle files started to look like this
dependencies {
compile 'com.android.support:appcompat-v7:23.1.0'
compile 'com.android.support:design:23.1.0'
compile 'com.android.support:pallete-v7:23.1.0'
compile 'com.android.support:cardview-v7:23.1.0'
compile 'com.android.support:recyclerview-v7:23.1.0'
}So when a new release comes out, we have to change the version number in every single line. Chris Banes, from the Android developer relations team, in Android Dev Summit 2015 has given this great tip to solve this problem.
\nThis! #AndroidDev #AndroidDevSummit
🙏 @chrisbanes pic.twitter.com/v47Pm74ohj
— Manideep Polireddi (@okmanideep) November 24, 2015Great! But there is a small catch here
\ncompile 'com.android.support:appcompat-v7:${supportLibVersion}' doesn't work
\ncompile "com.android.support:appcompat-v7:${supportLibVersion}" WORKS!!!
If you haven't noticed yet, you should use double quotes
\nSo the final code looks like this
\next {
supportLibVersion = '23.1.1'
}
dependencies {
compile \"com.android.support:appcompat-v7:${supportLibVersion}\"
compile \"com.android.support:design:${supportLibVersion}\"
compile \"com.android.support:pallete-v7:${supportLibVersion}\"
compile \"com.android.support:cardview-v7:${supportLibVersion}\"
compile \"com.android.support:recyclerview-v7:${supportLibVersion}\"
}By the way, Android Studio is intelligent enough that it will suggest you to update the version when there is a new one out, even in the above format. All hail IntelliJ.
\n", "date_published": "2015-11-23T20:10:00Z" } , { "id": "https://okmanideep.me/permissions-in-marshmallow/", "url": "https://okmanideep.me/permissions-in-marshmallow/", "title": "Permissions in marshmallow", "content_html": "I expect you to first go and have a look at this page in the Android Bible about permissions in marshmallow. Especially have a look at how to:
\nYou might have seen a code snippet like below in the training page.
\n// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
// Should we show an explanation?
if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
Manifest.permission.READ_CONTACTS)) {
//show user the reason for permission
} else {
//request permission
}
}Lets just dive into the only tricky part here - shouldShowRequestPermissionRationale() returns
The above code works pretty much in most practical cases. Let us consider this case:
\nThere is no way to detect using the above code that we were denied the permission, and ask him to grant the permission via application settings.
\nCheck for shouldShowRequestPermissionRationale() before and after asking permission. If it returns false both the times then the user chose 'Don't ask again' in the past or the device policy doesn't allow for that permission.
boolean before, after;
public void requestContactsPermission() {
if (ContextCompat.checkSelfPermission(thisActivity,
Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
// Should we show an explanation?
+ before = ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
+ Manifest.permission.READ_CONTACTS);
+ if (before) {
//show user the reason for permission
} else {
//request permission
}
}
}
@Override
public void onRequestPermissionsResult(int requestCode,
String permissions[], int[] grantResults) {
switch (requestCode) {
case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
if (grantResults.length > 0
&& grantResults[0] == PackageManager.PERMISSION_GRANTED) {
// permission was granted, yay! Do the
// contacts-related task you need to do.
} else {
+ after = ActivityCompat.shouldShowRequestPermissionRationale(
+ thisActivity,
+ Manifest.permission.READ_CONTACTS);
+ boolean goToSettings = !(after || before);
+ showRationale(goToSettings);
}
return;
}
}
}If both before and after are false, then show the user a dialog explaining that we need the contacts permission with a 'GO TO SETTINGS' button. On click take him to your application in the settings like this :
private void goToSettings() {
Intent intent = new Intent();
intent.setAction(Settings.ACTION_APPLICATION_DETAILS_SETTINGS);
Uri uri = Uri.parse(\"package:\" + getPackageName());
intent.setData(uri);
startActivity(intent);
}