<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>What's this? on Mark Aron Szulyovszky</title><link>https://almostintuitive.com/</link><description>Recent content in What's this? on Mark Aron Szulyovszky</description><generator>Hugo -- gohugo.io</generator><language>en-US</language><atom:link href="https://almostintuitive.com/index.xml" rel="self" type="application/rss+xml"/><item><title>What GitHub Actions Would Look Like If Designed Today</title><link>https://almostintuitive.com/docs/technical/github-actions-if-designed-today/</link><pubDate>Sat, 02 May 2026 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/technical/github-actions-if-designed-today/</guid><description>What GitHub Actions Would Look Like If Designed Today As with most of you, our small team’s velocity has increased a lot over the last 6 months. There is a “reimagining git(hub)” zeitgeist going on, and “actions” are a big part of that in terms of time and money spent for every productive team. They’re even more important now, right?
I think a world where llms/agents write most of the code (they do on our side), there are a couple of tweaks that may be optimal for “actions”:</description></item><item><title>Concept: Volatility Drag</title><link>https://almostintuitive.com/docs/quant/volatility-drag/</link><pubDate>Mon, 20 Jul 2020 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/quant/volatility-drag/</guid><description>Volatility Drag If you lose 50% of your capital in one year, you&amp;rsquo;ll need to achieve a 100% return the next year, just to get even. This asymmetry is the cause of the &amp;ldquo;Volatility drag&amp;rdquo; - one unit loss will hurt your long-term gains more than one unit gain.
This reason why you want to optimize your portfolio to avoid losses on your capital, rather for extraordinary gains.
The volatility drag could potentially explain the low-volatility anomaly</description></item><item><title>Observational studies</title><link>https://almostintuitive.com/docs/data/observational-studies/</link><pubDate>Mon, 20 Jul 2020 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/data/observational-studies/</guid><description>Why you probably shouldn&amp;rsquo;t trust observational studies 1. Undersampling failure Let&amp;rsquo;s say you&amp;rsquo;re doing research on why certain companies are more successful than others. Your data set only contains successful companies. You&amp;rsquo;ll have a lot of them taking huge risks, that combined with luck created runaway success. And you completely ignored the companies who took huge risks, but weren&amp;rsquo;t lucky enough, and ended up being bankrupt. Your sample naturally overweight the unreasonable risk takers.</description></item><item><title>Concepts: Alpha vs Beta?</title><link>https://almostintuitive.com/docs/quant/alpha-vs-beta/</link><pubDate>Sun, 19 Apr 2020 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/quant/alpha-vs-beta/</guid><description>Alpha vs beta Alpha Excess returns you gain over the market.
Only available to you. Requires you to have an edge (information that&amp;rsquo;s not baked into the price already). Zero-sum game. If you gain, somebody loses. Short-lived. As soon as the market finds about your edge, it&amp;rsquo;ll arbitrage it away. As a retail (non-institunioal) investor, your alpha (edge) sources are limited. Anything well-known is probably arbitraged away already (if it can be), by the time the info reaches you.</description></item><item><title>The reasons against discretionary investing</title><link>https://almostintuitive.com/docs/quant/the-reasons-against-discretionary-investing/</link><pubDate>Sun, 19 Apr 2020 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/quant/the-reasons-against-discretionary-investing/</guid><description>The reasons against discretionary investing 0. A financial asset&amp;rsquo;s price represents its concensus of its future, not just its present.
Eg. If you think Amazon will become more dominant in the future, and you have no insider information in your possession, you can bet that many others think the same, and using its past to extrapolate in to the future.
Its potential is already priced in by hundreds of thousands of participants in the market.</description></item><item><title>Sync APIs - git patch inspired non-blocking client-server communication pattern</title><link>https://almostintuitive.com/docs/technical/sync-endpoints/</link><pubDate>Sat, 04 Apr 2020 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/technical/sync-endpoints/</guid><description>Sync APIs - git patch inspired non-blocking client-server communication pattern Three years ago, we were in a desperate need for a mental model: how to structure the highly asynchronous, non-blocking communication we have between our backend and mobile clients - where Read/Update are the only meaningful operations.
The solution we ended up with was something different than the currently popular CRUD / REST APIs (but closer to GraphQL’s) - and rather close to the concept of git’s patches / diffs.</description></item><item><title>2016 - Functional Reactive Intuition - Swift edition</title><link>https://almostintuitive.com/docs/archived-posts/2016-01-30-functional-reactive-intuition-swift/</link><pubDate>Sat, 30 Jan 2016 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2016-01-30-functional-reactive-intuition-swift/</guid><description>Functional Reactive Intuition - Swift edition So, you’ve heard about reactive programming. Then you got discouraged, almost immediately.
Like: is this guy really talking about switching on the observable of observables? I have no idea what&amp;rsquo;s going on.
That’s all fine, we agree on one thing: people usually try to explain functional programming in a way that only makes sense to people who already know functional programming.
Let me show you something, maybe it can help with your appetite.</description></item><item><title>2016 - Big S(tate) notation</title><link>https://almostintuitive.com/docs/archived-posts/2016-01-09-big-s-notation/</link><pubDate>Sat, 09 Jan 2016 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2016-01-09-big-s-notation/</guid><description>Big S(tate) notation This is an early and somewhat funny/incomprehendible post I wrote a long time ago about stateless / stateful components (not in a React, sense, but more in an OOP, object-sense).
There’s something that bothers me a little bit:
We have this useful thinking tool, Big 0 notation, to measure the computation complexity of an algorithm / function.
And it&amp;rsquo;s great! We can anticipate the amount of time that a certain operation could take, and the necessary memory we need prepare for it, and it helps us architect our software, and forsee future problems without actually writing a line of code.</description></item><item><title>2016 - Making mistakes</title><link>https://almostintuitive.com/docs/archived-posts/2016-01-08-making-mistakes/</link><pubDate>Fri, 08 Jan 2016 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2016-01-08-making-mistakes/</guid><description>Making mistakes For a long time, my profile said “I make complex simple”.
Well, first of all, it would have been more accurate to say: &amp;ldquo;I try to make complex simple but I fail most of the time&amp;rdquo;.
Also, I don&amp;rsquo;t like the super-confident picture &amp;ldquo;I make complex simple.&amp;rdquo; is carrying.
So now I can rephrase my motto to: “I make lots of mistakes while trying to make complex simple”. But then, reducing complexity, keeping things as simple as possible is kind of what engineers do anyway, at least in my mind, so I can leave that out.</description></item><item><title>2015 - Post-text messaging?</title><link>https://almostintuitive.com/docs/archived-posts/2015-08-09-post-text-messaging/</link><pubDate>Sun, 09 Aug 2015 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2015-08-09-post-text-messaging/</guid><description>Post-text messaging? Have you ever been thinking about this little symbol?
I sometimes do. It gives me that anticipation, that sense of presence, which always makes conversations a lot more enjoyable.
I have a question though.
Why do we have this representation of a conversation as the standard?
This feels like something we inherited from here:
It does seem really useful to see the chronological order of the sentences, I have to admit.</description></item><item><title>2014 - Anatomy of a touch interaction: Swipe-to-peep</title><link>https://almostintuitive.com/docs/archived-posts/2014-09-07-anatomy-of-a-touch-interaction-swipe-to-peep/</link><pubDate>Sun, 07 Sep 2014 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2014-09-07-anatomy-of-a-touch-interaction-swipe-to-peep/</guid><description>Anatomy of a touch interaction: Swipe-to-peep You open up your messaging app. Question: Why can’t you just &amp;ldquo;peep&amp;rdquo; into the thread by swiping on a conversation cell like this?
Today’s state of interaction design seems a bit swipe-obsessive, right? But really, why do people love to cuddle their phone? Does swiping really make touch interactions seem more effortless?
Mailbox, the iOS app I’m using stopped working for a few days for me, so I went back to the Gmail app, and I was like, how can people use this?</description></item><item><title>2014 - Today’s mobile context-insensitivity</title><link>https://almostintuitive.com/docs/archived-posts/2014-03-24-todays-mobile-context-insensitivity/</link><pubDate>Tue, 25 Mar 2014 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2014-03-24-todays-mobile-context-insensitivity/</guid><description>Today’s mobile context-insensitivity The supercomputers we’re carrying around don’t know what we are doing and what we are up to — and that’s a problem.
I have an iPhone. The technology inside is so advanced that I can’t even imagine — and there’s no chance I can actually understand it. Its operating system has a built in physics engine, a database management system, OpenGL, and many awesome features and it would take me half an hour to list them all.</description></item><item><title>2013 - Life in a startup incubator</title><link>https://almostintuitive.com/docs/archived-posts/2013-01-25-life-in-a-startup-incubator/</link><pubDate>Fri, 25 Jan 2013 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2013-01-25-life-in-a-startup-incubator/</guid><description>Life in a startup incubator (I wish I had read this blogpost before I’ve got into one;)
Now there are so many chances to travel, form a company and spend a 3-month period somewhere in the world - more than 300 tech-only startup incubators exist at the moment.
We ended up in Estonia and got a seed investment from GameFounders, Europe&amp;rsquo;s first gaming accelerator. First of all, it was an experience of a lifetime.</description></item><item><title>2014 - Designing your personal identity</title><link>https://almostintuitive.com/docs/archived-posts/2014-01-01-designing-your-personal-identity/</link><pubDate>Tue, 01 Jan 2013 00:00:00 +0000</pubDate><guid>https://almostintuitive.com/docs/archived-posts/2014-01-01-designing-your-personal-identity/</guid><description>&lt;h1 id="designing-your-personal-identity">Designing your personal identity&lt;/h1>
&lt;p>So you are a graphic designer and you think you need a personal identity - not necessarily to show off your skills, but because you need to have one.
And designing it can cause a lot of problems. I, myself can&amp;rsquo;t even count the hours I wasted on experimenting with my own personal identity - and still, it&amp;rsquo;s in &amp;ldquo;beta&amp;rdquo; at best.&lt;/p>
&lt;p>I mean, how can you have something as a graphic designer that both represents your skills, your mindset and your style when all of these variables are changing extremely fast?
And I really do hope that none of them will eventually stop improving&amp;hellip;.&lt;/p></description></item></channel></rss>