I am personally waiting for the first viable consumer device by a major player like Apple/Samsung, with hand gesture support (without additional peripherals like gloves).
To me, that is the missing component for the entire sector to do a double-take, with of course at least a few hours of battery life.
I find it a refreshing experience to look at your own code from 10 years ago, or even 5 and think "Who wrote this shit?". If I ever look at some of my old code and feel good about it, that means I have failed to improve.
I've experienced some performance differences with UUIDs vs integers, but it has been minor enough to never cause any issues, even in tables with billions of records.
Does anyone happen to know of any geospatial indexing solutions that can also index simultaneously by other dimensions. Temporal indexing for example (not only where, but when)?
This reminds me of some wonderful 90s web games. Before XHR, an early web game built for Disney used a .gif as a one-way websocket to stream data into the webpage. This is due to the fact, that a .gif animation can be as long as you want and a server can generate an infinite animation, where some frames have content that you want to push and others are empty frames. Or in other words, they were using primitive video streaming to encode relevant information within the frames.
Not sure if it is true in general. But from the perspective of the software industry, our company has been remote-first since its inception. We do encourage coming to the offices, but it has never been mandatory. I think there is a fine balance in this. Personal time saved vs. the social aspect. And of course some problems just get solved faster in front of a whiteboard.
This could lead to an interesting situation, where in June of 2029 a multitude of double-spending attacks are initiated on various banking/financial software across the world, with the attack lasting a few seconds in total. What a headline that would be... Of course this depends on specific implementation, but I can see how this could happen to a wide array of implementations.
One of my comments in HN came up in a business transaction, where the opposing party wanted to know how a specific technical optimization problem I described, was solved.
Generally, I appreciate reading the thoughts of other people who have views opposing my own, but with reasonable arguments, in a calm manner.
The most amazing thing I saw with a microservices first approach was someone building a betting system with microservices. So if you made a bet, one microservice would make an http call to another to request your balance, make a decision based on that and then move the funds. No locks, no transactions, no nothing. I wasn't sure whether to laugh or cry. Fortunately I got there in time before this thing was launched...
I don't code in Lisp for work, nor do I prefer it as a language, but it has some really deep ideas that are useful regardless of what you build and what tools you use.
I think this discussion here is good. Whether it be an ORM or something like JOOQ it is always a tradeoff. I've found that the main pain point for me with these technologies is, that in any relatively complex project, you might want to query a similar but not identical thing in different ways. For either performance or business logic reasons. So lets say you have a POJO (in the Java world), that has a bunch of annotations on it. Once you need 3 different ways to query the same thing in different contexts, that breaks down. It also hides the database layer and structure from you, that you are in fact dealing with tables, not a hierarchy of objects, which can be misleading (especially to less experienced developers). We ourselves have gone the following route: All SQL is written as SQL (We use MyBatis for interfacing with that). And the only real features we use, are mapping and flow control constructs/loops for batch data. It is a lot more writing in that sense, but it also means that the query you write is the exact same one that gets executed. As for writing some database agnostic SQL, that can be executed on all of the big 3 (Oracle, Postgres, MySQL) - I have literally never seen anyone need that in practise. It also prevents you from optimizing to database specific features (in case of postgres, CTE is a good example).
This is a PEP/AML checking tool for developers of financial software. PEP lists are often hard to access or prohibitively expensive, so this is our attempt to launch a reasonably priced service, that you can try out for free.
The API is still in flux, but will be finalized for launch in January. Feel free to give it a try and be sure to share your thoughts and feedback!
It might have to do with the retina settings that rescale after rendering. I had this issue when we were testing 3DC.io on some Macbooks. Play around with the scale and css a bit, there is some information on Stack Overflow if you search for canvas+retina.
Edit: Also check out devicePixelRatio, that might be causing the issue as well.
Not sure about the stack Stripe uses, but if they do use Mongo, then they I presume they made it work well enough with a sheer force of will and reimplemented many ACID guarantees in the application layer themselves. That is of course assuming, that they started with Mongo early on, when it was still a bit wonky. I would love for a Stripe developer to jump in and share some background!
So most of the problems I have with using NoSQL type databases for financial data is related to the default settings and examples encouraging a model of programming, that will result in data loss, migration problems, race conditions, duplicate transactions. It's a bit like PHP in my mind, where you can write solid software, but in order to do so, you have to have very good discipline. I would rather choose a more constrained model, that forces you think about these problems and provides some safety out of the box. So in that sense you are right in your observation that my main issue with it is, that you have to mitigate problems, that shouldn't be problems. Then again MongoDB was never designed with those kinds of problems in mind and targets a completely different set of problems, which in itself is fine.
Edit: I'll add a few more thoughts. Financial data in essence is relational. It is also well shardable if scaling is an issue. There are many constraints that need to be validated and it is a natural fit in my mind.