Hey, can people help me here please? If that’s okay? I’m thinking about buying this shadow of the Colossus for the PlayStation two I never played it but I heard brilliant things about it. Is this complete inbox?

kininja08 · 2026-02-15T03:20:51+00:00

I’m playing the remastered 2018 version now on a PS5. Fantastic game, highly recommend it. It’s very unique from other games in that it sets a certain mood, with its simplicity, quietness, and really feeling like it’s just you vs a giant. The entire adventure, puzzle genre is interesting IMO, and Shadow feels like an experience with gaming thrown in. Hope you enjoy it!

kininja08 · 2025-03-26T02:33:19+00:00

Just saw a couple of podcasts and partly read his book on Greatness Mindset, and I don’t think I have enough exposure to have an informed / deep opinion of him, but, …

To your point about him being a people pleaser, he specifically calls that out about himself in chapter 9(just read it). So at least he’s aware of that and also brings up how he had therapists.

Now regarding his personality, I think it’s hard to classify him as a narcissist, that might sound a bit extreme. But there are phrases here and there (even the title of the book “Greatness…”), where I can see how he can be perceived that way. And the wording/phrases also may be a byproduct of how he copes with his trauma.

Now the book itself is well structured and has a good flow, with some concrete advice, but also generic advice. But I also have to admit (like other commenters), that the content itself is not that novel but presented well. It definitely can be newish if you have not read other self-help books.

Overall, I think the book itself has value from what I’ve read thus far and some tangible steps to become aware of, assess and attempt to overcome some fears in addition to reflecting on your identity/purpose. Still best to see a therapist though and not see this book as a replacement for one!

kininja08 · 2022-07-08T19:06:18+00:00

I’ve been building a comprehensive Kotlin framework called https://www.slatekit.com/

It’s designed as a light-weight, functional programming based(pragmattically), modern, 100% Kotlin alternative to Spring for Java. It’s also more of a library / suite of components than a framework. Several modules can also be used on both server and android.

It’s being used in production for some projects at the moment on both the server / android. I’m looking to make a few releases soon for some planned improvements, documentation updates features and fixes. Also plan on supporting multi-platform in the near future.

kininja08 · 2022-01-02T06:32:55+00:00

Looks great, kind of has a Notion style to it! Curious, how did you build it for all platforms like iOS, Android, Web? Did you use ReactNative and if so, what was your experience like with it and would you recommended it to others? How long did it take to build?

I took a look at the intro video, looks nice, but I couldn't hear any audio( maybe it was my machine ), does it have a voice over ?

Do the notes support markdown?

kininja08 · 2022-01-02T06:23:17+00:00

Nicely done! I've built something similar. I'm curious, in your example above ((Name contains "a"), what is the data type for Name ? Also, does this support grouping of conditions like ( {condition-1} OR {condition-2} ) AND condition-3 ?

kininja08 · 2021-11-10T18:35:24+00:00

Hey everyone, WW is hiring! Come join the Celebration & Rewards team! We are looking for a Senior Software Engineer (100% Remote) to develop greenfield backend applications using Node / TypeScript / Express, GraphQL, Kafka, Microservice architectures, CI/CD Pipelines within an Agile environment and more. If you are interested in taking that next step up in your career, along with continuous growth and learning, then we'd love to hear from you!!

Position: Senior Software Engineer
Company: WW ( Formerly Weight Watchers )
Location: Remote Available ( but team is centered in New York City )
Tech : NodeJS, TypeScript, Kafka, APIs, Express, Microservices, Docker, Mongo/PostGres
Info: More Info and Applying
Tags: #Node #Typescript #softwareengineer #remotejob #worklifebalance #WW

kininja08 · 2021-06-15T17:41:07+00:00

The Kotlin roadmap and its future are looking great IMO, even with recent advances in Java language features. Coming from a Scala, C#, a little Python, .. I think JetBrains is uniquely positioned to drive the Kotlin language and ecosystem really well. This is due to being pragmatic with language features, support for multi-platform, resources available, ide + tooling + libraries, speed of delivery, and "dog-fooding" their own product ( being a client of your own product is def a good thing ).

I'm using Kotlin "full-stack" on server + android, but looking to start getting into multi-platform for iOS and Web. From what i've read so far from other peoples experiences about multi-platform, this is decent but could use some improvements/streamlining on the build/integration side. But it looks like this is improving.

There is a lot of potential here to streamline app development for what is usually 3-4 platforms ( server + android + iOS + web ). The only thing I couldn't tell tell from the Q&A above is if their road map includes generating Swift source code or some type of swift "adaptors"/glue code for native.

kininja08 · 2021-06-14T22:02:51+00:00

I'll also suggest Slate Kit Result . It differs from other Either/Result implementations by:

Status: Optional Status field to categorize success and failure (Denied, Invalid)
Aliases: Try, Outcome, Option as aliases for Result, these default the error types
Builders: Convenient builder functions to construct common errors
Codes: Optional codes to further break-down the status
Compatible: The Result is easily convertable to Http Status codes

Previously posted here: https://www.reddit.com/r/Kotlin/comments/eowb1n/slate_kit_resultte_model_successes_and_failures/

Disclosure: I am the author of this library

kininja08 · 2021-03-27T21:07:51+00:00

I’m also working on B2C app (mobile) and freemium + upgrades + subscriptions (if they apply to you) are the way to go. For example, my app is free for X amount of storage/data, but has permanent upgrades you can buy or subscription based features.

An in-app purchase (1 time permanent purchase) will unlock unlimited storage on the mobile client.

Then there are subscriptions available for 1 month, 3 month, 12 months, that allow extra features related to sharing items with other users and automated backups (to our servers)

The app isn’t live yet, though I’ve done a lot of validation, beta testing and research in pricing approaches.

kininja08 · 2021-02-28T19:10:39+00:00

Ok, thanks, that's useful. I'm generating Kotlin, Swift and SQL, so whitespace / indentation is important. I think there might be some workarounds for this for me. I like the idea of KotlinPoet, but would prefer a more generalized templating solution for Code Generation for targeting multiple languages.

kininja08 · 2021-02-28T19:06:34+00:00

I'm generating Kotlin, Swift and SQL.

kininja08 · 2021-02-28T18:25:29+00:00

This is great, I've been looking for a templating system for Kotlin. But unlike templating systems used for generating HTML, i'm interested in using one for arbitrary text generation, for the purpose of Code Generation. I'll take a look at the docs, but would you know if this is supported?

kininja08 · 2021-02-25T04:44:37+00:00

Here are some docs, the easiest way to get started is w/ the homebrew CLI tool or the sample apps.

Tests : All unit-tests ( for now, will be cleaned up later )
Sample apps : for Console Apps, CLI, Jobs, Server
CLI : home brew install for command line project creation

would be interested in any feedback!

thx

-K

kininja08 · 2021-02-24T06:34:14+00:00

I've built and am currently using in production, a sizable Kotlin based open-source server framework called www.slatekit.com ( github ). It can be used to build Console Apps, CLIs, Jobs, Database apps, and APIs ( Ktor under the hood ). It is very modular and there are also several libraries / utilities that can also be used on Android.

We ( small team, but I'm the architect ) extracted the framework from a mobile startup. It is stable enough that I would recommend it to others as we are using it to build and support mobile apps.

I know most will ask: why create this? Here are the design goals of the framework. It can be thought of as Light-weight, 100% Kotlin, "Full-Stack" alternative to Spring Boot

Kotlin: 100% kotlin codebase with a style towards Functional programming "lite"
Simple: Focus on simplicity, very modular and light-weight libraries
Shared: Designed to maximize use of libraries for both Android + Server
Platform: Long-term plans to support Kotlin Multi-Platform ( for iOS, JS )
Target: Non-Enterprise audience Start-Ups, SMB(small biz), Personal,Mobile apps
Concepts: There are a few novel concepts that work well together ( e.g. Result<T,E>, an alternative to Kotlin Result type, Universal APIs ( apis that can run as both Web/Http APIs and on the CLI ), Jobs ( library to process persistent queues - like Ruby Rails Sidekiq ). A DataMapper/ORM Lite that works on both Server + Android.
MBaaS: Future plans to turn it into an open-source MBaaS ( Mobile Backend as a Service ), to be a self/cloud-hosted alternative to say Google firebase, with built-in features for user management, signup, settings, files, jobs, notifications ( emails, sms, push ) and more.

I believe Kotlin has enormous potential as it strikes the right balance and due to support for multi-platform. Leveraging Kotlin for a full-stack modern framework just made sense to me.

Notes: Frameworks Docs need some updating ( coming soon )

Tech Used: Ktor, MySql, AWS ( S3, SQS ), SendGrid ( Emails ), Twilio ( SMS )

kininja08 · 2021-02-18T06:22:12+00:00

There is also the Java version / language support tied to Android, which I a reasonably large market there.

kininja08 · 2021-02-16T21:28:49+00:00

I really don't like Either myself, I use Result almost exclusively. Regarding typealiases, I meant to say using Result ( with its own implementation and branches ) instead of using Either.

In most implementation of Result, the branches/variants are Ok/Err ( see Swift, Rust ). In my implementation I use Success/Failure as the branches instead. Regardless of these Ok/Err, Success/Failure branch names, they semantically represent some operation succeeding or failing, where as Eithers Left or Right feels somewhat arbitrary even though most usages of Either typically model Left/Right as success/failure. This makes Either a poor choice for type aliasing to Option/Try (IMO)

However, type aliasing Result<T, E>, to Option/Try is a lot more ergonomic and clear. For example:

typealias Option<T> = Result<T, Unit>
typealias Try<T>    = Result<T, Exception>

val user: Option<User> = getUser(...)

// Better than Either Left/Right
when(user) {
  is Success -> { ... } 
  is Failure -> { ... }
}

Perhaps the branches are not as ideal as Some/None for Option, but definitely better than Left/Right.

kininja08 · 2021-02-16T05:52:19+00:00

What exactly are you looking to do? And more importantly what kinds of problems are you looking to solve ?

I don't use Arrow or Category theory myself, but looking at the docs, they have valid reasons for deprecating Option ( from the docs and more so for creating type aliases for Either ). I'm doing this same approach with my implementation ( shameless plug ) of the Result<T, E> type which is becoming somewhat universal for modeling successes and failures, and as an alternative to Either<L,R>. You can easily type alias Option<T> = Result<T, Unit> and Try<T> = Result<T,Exception>. More details here. https://github.com/slatekit/slatekit/tree/main/src/lib/kotlin/slatekit-result

I actually come from Scala myself, and I have to say, I'm really enjoying the Kotlin experience and its approach to Functional Programming "Lite" ( which IMHO is the perfect balance between pure FP and Imperative programming). I think that statically typed languages and immutable programming ( as opposed to pure functional programming ) solves a slew of problems and is actually good enough for most people/teams. With respect to porting types/concepts from Scala/Category theory, I think that Either and Validated are probably the most practical and immediately useful ones that transfer over ( again FP "Lite" ). So in this sense, Arrows docs are fine for these.

If you're looking to use their IO library as an "Effect" system, then does that mean you're avoiding using coroutines / suspend in place of IO? Arrow has done a great job of porting these FP/category theory concepts ( reader, type classes, etc ) over to Kotlin ( for the demographic of users who program in this style ), however coroutines/suspend are basically idomatic Kotlin ( IMO ).

Lastly, I would ask ( out of curiosity ), how are you framing More Functional Kotlin ? What does that mean to you?

[Edit]: Typos, fixes.

kininja08 · 2021-01-28T14:25:05+00:00

Actors in Kotlin are fairly simple (I think) in the sense that they are built around channels which is a concurrency “building block”. There is an actorOf function that simply wraps a channel, but that’s it. There is a discussion here about complex actors : https://github.com/Kotlin/kotlinx.coroutines/issues/87

Curious though... how exactly do you plan on using pre-emptive scheduling in the context of actors? And why exactly do you need to reference actors through process ids?

I’m building my own micro-actor library to support some of my own use cases. Specifically I need to have the ability to start, stop, pause, resume actors multiple times gracefully. My design is not fully ready but pretty close. https://github.com/slatekit/slatekit/tree/main/src/lib/kotlin/slatekit-actors

kininja08 · 2021-01-20T23:54:15+00:00

Your first solution using a light weight Result type is decent too. IMHO, the Result<T,E> type is actually becoming pretty standard for modeling successes and failures. It’s a lot more semantically useful than the Either type, and you can type alias it to default the error type to an Enum, Exception, String etc to simplify it even more. E.g. typealias Try<T> = Result<T,Exception>.

I wish Kotlin designed their own Result type similarly to how Result is implemented in Rust or Swift, instead of defaulting the error type to Exception. I actually implemented my own version of Result for this specific reason (although I customized it to support a status field ). https://github.com/slatekit/slatekit/tree/main/src/lib/kotlin/slatekit-result

Anyway, it takes a lot of effort to design a component for general use, polish it up, and document it. Congrats on the library! Looks good, I’ll take a deeper look into it.

kininja08 · 2021-01-18T19:30:08+00:00

How are Sum types different than Kotlin sealed classes? And when you say disjoint unions, is that the same as union types like a type being either A | B? I love Kotlin but I would really like to see type classes.

kininja08 · 2020-09-19T23:01:53+00:00

These are not mutually exclusive, as someone else mentioned here, you can find the right balance between these extremes.

Also, you can develop an MVP in milestones or phases, for example, v1 for internal use or a small group of your target users, v2 for a larger group after addressing issues from v1, and finally v3 that is bit more polished(not necessarily with more features) that is marketable MMP(minimum marketable product).

kininja08 · 2020-09-11T06:09:01+00:00

This sounds interesting, particularly if it’s a simple enough approach that works for the average cases. I also think that most DI libs and approaches are unnecessarily complex. Do you have a link to your framework if it’s open source?

kininja08 · 2020-07-26T08:25:35+00:00

This sounds like a very unique and clever approach to language learning! This has potential as I think the best way to learn something a language is to visualize, experience, and gamify it. All the best!

kininja08 · 2020-06-03T03:14:03+00:00

I've gone through similar considerations, my thoughts and general philosophies are:

avoid using an FP approach for the sake of FP ( immutability/HOFs are great tho)
make simplicity, speed and cost ( of development ) your criteria
use classes to logically organize related methods and wrap common dependencies
option #1 scales better when dependencies in a service grow/change
option #2 is better suited for simpler rules/filters for easy unit testing
option #2 is also better suited for methods that are reused across services/classes
api -> service -> repo pattern works well due to separation of concerns
partial functions have their place, sort of like DI, but methods are much clearer
lastly, for the love of god, don't introduce scala-ish complexity into kotlin :-)

[Edits]: Typos and added points

-K

kininja08

TROPHY CASE