Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
sudowhodoido
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
by
sudowhodoido
12y ago
Yes definitely. The previous solution was thoughtless and poorly abstracted so there were queries with tens of joins all of which multiplied IOPS and index lookups considerably. The dataset is too large to fit in any reasonable amount of RA
32.
▲
by
sudowhodoido
12y ago
Fair point but it's a terribly light ORM behind an abstraction boundary that doesn't make assumptions about the type of store it is communicating with. We don't write any hydrators. On our previous solution they are generated
33.
▲
by
sudowhodoido
12y ago
Actually we use both. Both have their advantages so we use SQL Server and Redis. The data model is what we're exposing, not the table model.
34.
▲
by
sudowhodoido
12y ago
Query object. The interface is as follows (I simplified a bit above: public interface IStorageQuery<T,Q> where Q : IStorageQueryCommand { IEnumerable<T> Query(Q query); } IStorageQueryCommand is an empty
35.
▲
by
sudowhodoido
12y ago
After years of using Hibernate and NHibernate, considered best of breed and most well thought out and thoroughly engineered ORMS, I agree. They fall of a productivity cliff pretty quickly, particularly on larger projects (I'm talking t
36.
▲
by
sudowhodoido
12y ago
I can't think of any reason I'd want any less POSIX. In fact more is probably better for us all.
37.
▲
by
sudowhodoido
12y ago
Hibernate comes to mind as a use case. That's always crapping huge stacks in production thanks to obscure edge cases.
38.
▲
by
sudowhodoido
12y ago
Yes precisely. I was hoping someone would reply with that. The Granny Smith starts of as an acidic yellow ball of death, progresses through a window of being edible over the space of 2 days and then instantly turns into a rotten fermenting
39.
▲
by
sudowhodoido
12y ago
As yes I read that a couple of months ago. I always wondered how we'd model general relativity on top of all of that (after reading Orson Scott Card's 'Ender' series).
40.
▲
by
sudowhodoido
12y ago
Well the mature Granny Smith tree in my garden has nearly given me diabetes from the amount of crumble and pie that it has blessed us with and ruined the liver of many thanks to the reliable yearly cider production (affectionately known as
41.
▲
by
sudowhodoido
12y ago
Both. I do anything that comes by. I'm currently contracting to a large financial company in the UK, fixing a pile of laptops to sell on ebay, doing a couple of web sites for people in europe and rewriting an ASP.Net web app for a comp
42.
▲
by
sudowhodoido
12y ago
That's interesting. I appear to have actually accidentally written a chunk of this in C# for a product a couple of years back. The approach is pretty much identical.
43.
▲
by
sudowhodoido
12y ago
Lie to them to bump it up or tell them that your previous employer asked not to disclose it. Works every time. They're using a standard technique to smack your pay down and it works for a lot of people but there's nothing wrong wi
44.
▲
by
sudowhodoido
12y ago
This. And I'm always having to clean up dinosaur shit! (rotting corpses of processes and management hierarchies)
45.
▲
by
sudowhodoido
12y ago
Get rid of tabs and you have IE6 again.
46.
▲
by
sudowhodoido
12y ago
That's a really cool idea but I suspect that this would be down to the inevitable problem of "cost". Getting the equivalent of an EV cert for some backwater country's crap mouse with a major brand stuck on the case would
47.
▲
by
sudowhodoido
12y ago
We use printer accounting to get around this. Everything is billed to the relevant departments at an extortionate rate per sheet. The department has to pay the print bill out of their budget. Printing has nearly stopped to the point that so
48.
▲
by
sudowhodoido
12y ago
I think that avoiding complexity in the build system is the priority rather than avoiding a product that has cruft in it. Make can be simple, elegant and productive even on large projects if you think before you do something. For example SC
49.
▲
by
sudowhodoido
12y ago
I'm not ashamed to say that I'd be using a 3310 now but you can't get reliable batteries any more. That leaves only later Nokia dumbphones which are the same in spirit but inferior in usability.
50.
▲
by
sudowhodoido
12y ago
I thought that until it destroyed one of my notebooks. All 55 pages of it. I now use vim outliner and svn.
51.
▲
by
sudowhodoido
12y ago
Ugh it's horrible. Reinstalling now.
52.
▲
by
sudowhodoido
12y ago
This. Sten plans to give you an idea how easy this is: http://stevespages.com/pdf/sten_mk2_complete_machine_instruc... Really don't need much of a machine shop to knock one of them out.
53.
▲
by
sudowhodoido
12y ago
Going to dogfood it as a primary workstation for a few days as well and see what happens. My laptop needs trashing anyway and everything is backed up regularly so I've got nothing to lose other than a couple of hours max. Plus it'
54.
▲
by
sudowhodoido
12y ago
In the age of high level languages and compilers, that's exactly what they should have done, possible twice by now.
55.
▲
by
sudowhodoido
12y ago
Good point! I'd completely forgotten about arm64.
56.
▲
by
sudowhodoido
12y ago
I agree entirely with you. However that doesn't invalidate my point.
57.
▲
by
sudowhodoido
12y ago
No they didn't have SLAT/EPT then. That came in with the i-series processors. The processors were knee deep in errata and buggy as hell. As they are now: http://www.intel.co.uk/content/dam/www/public
58.
▲
by
sudowhodoido
12y ago
Yes. See: http://marc.info/?l=openbsd-misc&m=118296441702631
59.
▲
by
sudowhodoido
12y ago
Not really. He's right. The memory, paging and protection model for X86 is fugly at best. It's very easy to hang yourself as demonstrated. You can be as insulting as you like if you compare X86 (and X86-64) to SPARC and POWER whic
60.
▲
by
sudowhodoido
12y ago
Well looks like Mr De Raadt was right again: 'x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your
More ›