tolitius

The “Dad” Problem

My kids are navigating the ways of middle/high school: one is deep in ionic bonding in Chemistry, another one is grappling with graphing sine waves in Pre-Calculus.

I can explain these concepts to them with words, or I can scribble on a napkin (which I love doing), but some concepts just need to move. They need to be visualized. I could write a Python program or a D3.js visualization for every single problem, but that takes too long, even when done directly with “the big 4“.

I needed a way to say: “Show me a covalent bond in H₂O” and have the visualization write itself, test itself, run itself, and show me that interactive covalent bond moving step by step.

Great fit for a “Skill” I thought and built Salvador that can do this.

more details here: https://www.dotkam.com/2026/01/06/mad-skills-to-learn-the-un...

Claude Skill to visualize anything

what needs to be written to create a project and build/run it is:

    lein new twitter
    lein run

Most of the info in this article just reflects the rightful excitement form the author, but not in any way the best or the simplest way to do things. Just take it as "I love it, let me share" vs. "Clojure is better than..."

a simple fact that you get defensive and personal reveals that you are not happy with your confidence level. but that's ok, as you get more mature, and acquire a certain perception depth (and I wish you do), you'll prefer being constructive vs. angry.

I didn't mean to hurt your feelings. Hazelcast solves similar problem that all of the valuations in the list: "storing and retrieving data". By the way, "file system" does it too (let's valuate it as well @ $3.6B).

As far as "enterprise support" in case of Mongo, it's like running a political campaign: nobody really knows "who" is inside, until "he" gets elected, and when "he" does, the "support" needs to make sure reality stays hidden, by white (and not so white) lies. And yes, MongoDB is great at "support", most OSS aren't.

Ok. Time to change how the hype and good marketing drive mediocre products, with average people behind it, to silly valuations.

So here it comes. It is only a VALUE if WE say it is. So here is what I say.

I value

    * Redis      @ $4.5B
    * Datomic    @ $4.5B
    * Riak       @ $3.2B
    * Hazelcast  @ $3.0B
    * HBase      @ $2.5B
    * Spanner    @ $2.1B
    * Neo4j      @ $2.0B
    * MongoDB    @ N/A

or, given the quality of existing async/fsync guarantees, they'd be better off with just taking the money and running.. away.. fast

it's so rings a bell: http://www.dotkam.com/2008/11/19/zx-spectrum-child/

Раз ты так хорошо шаришь в английской грамматике, и тебя так напрягает нехватка запятых и дефисов, подскажи как лучше сформулировать и "пруфридать" вот это самый комментарий, или... у тебя эта самая пустота в одной из частей твоего, грамматически заточенного мозга (там, кстати, дефис можно поставить) мешает тебе справиться с задачей?

в следующий раз (кстати с заглавной буквы можно начать) перед тем как насилывать свою клаву, лучше пойди на подкурсы русского или китайского или хотя бы того же английского.

очень не сложно оставлять мусорные комментарии, не относящиеся кстати к теме разговора, и называть себя викинг кодером. гораздо сложнее соответствовать своему имени, и "викинговать" архитектуру, код, мысли, философию создания.

если бы в интернете и/или на хакер ньюз была бы общая корзина для мусора, и можно было бы голосовать за вещи которые туда отправляются, можешь расчитывать на мой голос.

hey VikingCoder, I heard you are a fan of grammar? see above? grammar that.

1. Timestamps in your seed data might benefit from nanoseconds if you really talking about "high" frequency.

2. I agree with you comment that it is easier to think about concurrency in Haskell than in something like C++, however you can't really compete with C/C++ in Haskell. Not even with cgo (Go packages that call C code), not with OCaml or any other higher level beasts that promise the speed. Fortran would be the only one faster for the "algo" part of your initiative. But again, if this is just an exercise, Haskell and others (I prefer Clojure for example :) will do just fine.

3. Would make sense to split the "platform" in two (very different) parts: "Quantitative Analysis" (a collection of tools and rules) and "Technical Glue to Read and Stream". Each can/should be divided further of course, but the two above are essential yet very different for a true "HTF Platform".

market makers work (have deals) with exchanges. e.g. a market maker M guarantees to provide liquidity (e.g. orders) for a certain set of securities to an exchange E, and gets certain benefits in return.

This market maker M makes sure that he is as close as possible to the exchange metal, so he has an upper hand.

The importance of colocation is directly proportional to the liquidity (amount of orders) you provide. e.g. if you send orders manually every minute or so, it does not really matter where you are in comparison to a large bank that sends orders every several microseconds..

there are several books including a "public book" that all exchanges publish and an "internal book" that each exchange has.

in case of the "internal book", it is always ahead of the "public book", as changes to it "published" after events occur internally and this "internal book" is updated.

this is important bit, as an individual exchange "knows better/earlier" than the "public".

how cool would a white Thinkpad be looking like a a beautiful Macbook Air...

I hope Lenovo gets their shit together and release a sexy version of Thinkpad with Apple's trackpad. So I am no longer hooked on Apple and can get back to Ubuntu, as it is a far more superior platform for development.

Until then, a touchpad alone on my Mac Book Pro kills all the laptop wannabes..

great post. direct and to the point, although there are many more flaws that I am sure you could have shared.

we tried MongoDB to consume and analyze market feeds, and it failed miserably. I can add a couple of things to your list:

* if there is a pending write due to an fsync lock, all reads are blocked: https://jira.mongodb.org/browse/SERVER-4243

* data loss + 10gen's white lies: https://jira.mongodb.org/browse/SERVER-3367?focusedCommentId...

* _re_ sharding is hard. shard key is should be chosen once and for all => that alone kills the schemaless advantage

* moving chunks between shards [manually or auto] can take hours / days depending on the dataset (but we talking big data, right?)

* aggregate (if any complex: e.g. not SUM, COUNT, MIN, MAX) over several gigs of data takes hours (many minutes at best). Not everything can be incremental..

Those are just several. MongoDB has an excellent marketing => Meghan Gill is great at what she does. But besides that, the tech is not quite there (yet?).

Nice going with Riak + PostgreSQL. I would also give Redis a try for things that you keep in memory => set theory ftw! :)

the point is there are only several. and there is a huge difference between a "loud mouth marketing engines" and "true tech".

I find SO rather too addictive. I "played" it for a month, even got in "top 0.2%" for one of the weeks. It was tons of fun, but... no healthy balance.

Now days I still consume almost every day, but produce a bare minimum ( very similar model to US economy :) ).

I love SO, but I understand complaints about "rude" comments and lots of duplications. The thing is most people even with 10K+ ratings don't really know the subject (and got there by producing that same "duplication" instead of "closing as duplicate"), and these very people tend to be a lot ruder, since it is a "self defensive" way to a "self proof" that they really are worth something ( e.g. Psyc 101 ).

However people who really "grok it" tend to be the most helpful and fun to talk to.

Oh.. and the search. SO search sucks. I always Google my way into site:so in order to find anything.. But I guess SO knows there is Google, and does not care. Well I do! Fix it! :)

Again, SO rating mostly became a game, and since now it can also mean something on a resume (although personally I don't believe that resume itself means anything), more and more people try to game the system, and many of them winning the game. e.g. two years ago the content on SO was _really_ to the point. Now you need to click around to "find it". Two years from now... something new will emerge? :)

"Is it time for me to leave the coding thing and get an MBA?"

Do you need someone to tell you a "supportive" NO, or you want to hear an encouraging "YES"?

Do you need MBA? Go for it. But don't blame Java.

Do you NOT need MBA? Don't go for it. But don't blame Java.

don't think anybody can really help you here, but things to try that come to mind..

    * have kids
    * have friends that you can touch
    * have an affair
    * travel
    .. ...
    * put "127.0.0.1 news.ycombinator.com" in your "/etc/hosts"

would also be cool to have a code highlight.. (ala https://refheap.com/paste )

the answer to "how much" is aways "it depends".

* tech stacks evolve changing the amount of testing that is needed => most of the stacks allow to only focus on the "meat" of the logic, rather than things like integration (Spring Integration / Camel), network (Netty), cache (Redis) or even data structures (various language built ins).

* human is getting better with years of coding => I spot flaws and mistakes during code reviews N times faster than I did 10 years ago. I code in little pieces (usually functions), which "talk" back to me immediately even before they are finished.

* REPL is getting really good => Clojure, Scala, Ruby, Groovy, etc.. REPLs save lots of time and prevents mistakes: where a 5 minutes REPLay session reveals a nice and polished approach a lot quicker than a "let's try this / now rerun the test" formula.

* Domain knowledge and "'ve done this exact thing before" greatly impact amount of testing needed => e.g. deeper domain knowledge allows for [better] tests, while no domain knowledge requires lots of prototyping (even if you think it is the "real thing" at first, it is not, it's a prototype), and would greatly suffer from a large number of tests, as most of the time will be spent rewriting test instead of learning the domain.

In the end, the rule of thumb I always use is "do whatever makes sense". I don't buy TDD, ADD and other DDs. They are fun to read about, but they are too removed from the "real thing". If any DD term is needed, what I use is MSDD => "Making Sense Driven Development"

I agree. Setting up Cassandra is simple. It is later when you get to things like:

    mutator.setColumnOrSuperColumn( ... )
    mutationsMap = new HashMap<ByteBuffer, Map<String, List<Mutation>>>()..

    compound column..
    super compound family of super columns...

    curl POST '{"red":2, "blue":4}' http://127.0.0.1:8091/riak/laundry/shirts

"How do you get that inner Zen back where you can focus on personal projects and really enjoy what you do?"

It might be a personal thing.. but the "inner Zen" relies mostly on self confidence, and it is ok not to have it constantly. Especially when approaching new things with lots of unknowns. It is actually cool to experience a discomfort, since it sparkles fresh ideas. But again... sometimes.

Why can't you enjoy your personal projects now? If choosing a "tech stack" is a problem, then choose literally anything that has a live and matching (to you) community around it. You are looking at Rails, and you like what you see, people you talk to (IRC, forums, groups, conferences)? Go for it, and have no fear of missing out on anything.

step zero is to have common sense.

    "Bob:           I quit my job to create a cool startup"
    "Bob's friends: (applauses) Wow, Awesome Bob!"

but what does work is "common sense", which gets overlooked and dismissed constantly in favor of "advice" from Iknowitall wannabes.

how about a library with a price list:

    * { chmod777.jar:   25c }
    * { chown-R-me.jar: 75c }
    * { rm-rf-star.jar: 1 dollar }
    * { rm-rf-/.jar:    monthly salary }
    ...

writing code during an interview is great, but almost a 180 degree experience to writing code in real life. there are a couple of factors:

* psych pressure

* unrealistic timeline

* googling is usually not allowed, whereas EVERYBODY uses it writing code in real life

* editor/environment is usually not "yours"

* etc..

hence the _way_ you choose to conduct a code test will, in most cases, matter a lot less than the actual _problem_ you choose that needs to be solved. the more applicable this problem is to what your business does every day the better. e.g. sometimes a "red-black tree" is crucial, other times things like a simple mobile CRUD app with a REST web service OR a thin, high throughput TCP/IP based protocol could be a lot more relevant.

of course you can't realistically expect a 100% bug free or even complete code from candidates, especially if you ask for things like an "app" or a new "protocol" => what really matters is _how_ people "get to it".

github or not, I hired several exceptional people not that long ago using a piece of paper and a white board. If it is not a face to face interview, skype and/or google docs are also effective.

http://www.dotkam.com/2011/07/06/noram-db-if-it-does-not-fit...

I agree PR and lots of BUZZ makes it really difficult to choose the right DB.

My latest obsession is Riak => Basho is VERY honest, and quick in helping you out and telling where and how Riak can help you, and most importantly what would NOT be a good fit for Riak. ( I am not working for them :)

/Anatoly