With version 10 Google stopped referring to Android versions using dessert names. Internally these names do still exist however. With version 13 I'm seeing external references to the desserts again.
If your starting Kotlin with prior java knowledge, here's a quick lookup table for some common equivalents:
|
Java |
Kotlin |
|
Accessibility modifiers:
|
|
|
String [] anArray; |
var anArray:Array<String> |
|
(castType) |
smart casting after is as |
|
public class Area { private int length; private int width;
//constructor public Area(int length, int width){ this.length = length; this.width = width; System.out.printf("Surface: %d",length*width); }
//accessor public int getCircumference(){ return 2*(length+width); } } |
class Area(var length: Int , var width: Int) {
//to add onstructor code init { println("Surface: ${length * width}") }
//accessor val circumference get() = 2*(length + width)
} |
|
anEnum.values() |
anEnum.entries |
|
class Shape{} class Rectangle extends Shape{} |
open class Shape {} class Rectangle : Shape {} |
|
final String aConstant="a"; |
val aConstant="a" |
|
instanceOf |
is |
|
Primitives: int, double... |
Int,Double... |
|
lambda (shorter forms exist in both languages) BiFunction<Integer, Integer, Integer> mutiply= (a, b) -> { System.out.println("java lambda"); return a * b; };
|
val multiply: (Int, Int)->Int = { a, b -> println("kotlin lambda") a * b }
|
|
new Random(); |
Random(); |
|
Object |
Any? |
|
public static void main(String[] args){} // Note: Java 22 has a preview of a main() function |
fun main(args:Array<String>){} |
|
static |
companion top level function const |
|
switch expression
|
when |
|
int ternaryVar=test?1:2; |
var ternaryVar = if(test) 1 else 2; |
|
throw UnsupportedOperationException |
TODO() |
|
void |
Unit |
The yearly large IntelliJ release (2024.1) is out with a host of new features. Here's a list of highlights
After settling a lawsuit, Google will destroy tracking information it collected on websites containing google tracking (analytics) or advertising info for users browsing in incognito mode.
It only collected information if
Data will be deleted on about 136 million users.
Separte from the lawsuit, Google is also phasing out usage of third party cookies in Chrome. Currently you can configure chrome to block third pary cookies, it just is not the default as it is in Firefox and Safari.
In a study in Nature the taste of a potential recipe for a Belgian beer is being predicted by Machine Learning based on its chemical components at KUL (Catholic University Leuven).
One of the primary goals of the study is brewing better tasting alcohol free beers.
The techniques used are also interesting for being tested on other types of food.
In an earlier post we explained how we moved from ts-node to tsx.
For testing we were using Jest. Unfortunatly Jest relies on ts-node for reading typescript configuration files. We used ts-jest for the configuration and even then we needed quite some configuration in jest.config.ts to work with ESM:
import type { JestConfigWithTsJest } from 'ts-jest'
const jestConfig: JestConfigWithTsJest = {
// [...]
preset: 'ts-jest/presets/js-with-ts-esm', // or other ESM presets
moduleNameMapper: {
'^(\\.{1,2}/.*)\\.js$': '$1',
},
transform: {
// '^.+\\.[tj]sx?$' to process js/ts with `ts-jest`
// '^.+\\.m?[tj]sx?$' to process js/ts/mjs/mts with `ts-jest`
'^.+\\.tsx?$': [
'ts-jest',
{
useESM: true,
},
],
},
}
export default jestConfig
Vitest is built by the Vue community, who also made the vite build tool. As the name suggest, vitest's natural habitat is vite (which we are not currently using), but it runs without vite.
Like tsx it is a modern tool, built with support for typescript and ES modules builtin, and setup was a breeze.
Just like tsx, it has a builtin watch mode. This mode is even the default: you run your test, then you correct our code and the test automatically reruns.
We adapted the test scripts to our package.json:
"scripts": {
"start": "tsx watch server.ts",
"debug": "tsx watch --inspect-brk server.ts",
"build": "tsc",
"test": "vitest",
"coverage" : "vitest run --coverage "
}
Vitest's testing API is heavily inspired on, and compatible with Jest, easing migration. The only things we had to change, were some imports.
Stackoverflow will charge AI companies for usage of its data and will require attribution back when its answers are used.
More info...JavaScript is a fast changing ecosystem. With so many new and old kids on the block there are so many options that having them play nicely together is a challenge.
We're working with node.js 18 at the server side and have moved to using TypeScript (instead of JavaScript) and ES modules (instead of CommonJS modules).
We're using ts-node to feed node TypeScript, and added extra options to our tsconfig.json for this:
{
"extends": "@tsconfig/node-lts/tsconfig.json",
"compilerOptions": {
"module": "ESNext",
},
"ts-node": {
"esm": true,
"experimentalSpecifierResolution": "node"
}
}We're using nodemon to restart node upon changes.
This was giving us some problems when launching in debug mode, so we had to explictly pass the ES module loaders of node to nodemon. These are our commands in package.json
"scripts": {
"start": "nodemon index.ts",
"ts": "ts-node ",
"debug": "nodemon -x \"node --inspect --loader ts-node/esm \" "
}
For both npm run ts and npm run debug we're appending the ts file to be run.
We're testing with Jest and again we needed some extra configuration to play nicely with Typescript and ES modules.
And then we moved to the Node.js 20 LTS release and things broke. It cannot even grok @tsconfig/node-lts/tsconfig.json (es2023 not supported). You can get things going by also passing the esm loader when running the code normally, just as you do when you're debugging.
But really, not running with the LTS seemed a bit lame to me for a tool like ts-node. The 10.9 release dates from juli 2022, with only two bug fix releases since, and no sign of updates for new releases of underlying packages.
So, we took a stab at tsx as
an alternative for ts-node. If you look at the comparison between the
two (by tsx, but still informational), you see that tsx has less
downloads (6M/month vs 94M/month), has a larger footprint (10 MB vs
2MB), has less github stars (7k vs 12k).
Trying out tsx we could reduce tsconfig.json to sensible defaults
{
"extends": "@tsconfig/node-lts/tsconfig.json",
"compilerOptions": {
"outDir": "dist"
}
}With this setup we are importing files with a .js extension, even if we are developing with .ts extensions. We need to avoid picking up previously generated .js files is compiling with tsc, so we are directing compiled files to a dist directory.
Annoying downside of tsx is that its name overlaps with the .tsx file extension (React typescript file), which gives you false positives when googling.
Also, we did not need nodemon anymore, as tsx comes with a watcher. Our scripts commands in package.json have simplified to
"scripts": {
"start": "tsx watch index.ts",
"ts": "tsx ",
"debug": "tsx --inspect-brk "
},
I have not tried out (Jest) testing yet, but as for now, tsx looks like the way to go!
Posts
All Comments
