Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
LnxPrgr3
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
26 ms
·
151.
▲
by
LnxPrgr3
14y ago
We're not talking micro-optimization to squeeze an extra 0.5% performance out of a system. We're talking about an order of magnitude (or more) slowdown, in a language already not exactly known for its blazing speed. My question of the day:
152.
▲
by
LnxPrgr3
14y ago
Personally I wouldn't, but my opinion doesn't matter. Does TDD help you? If so, use it! If not, don't! The whole point of an MVP is to ship something ASAP. Do whatever helps you do that. Personally I've found TDD to be a tremendous waste of
153.
▲
by
LnxPrgr3
14y ago
You know what's funny? I like native apps for a lot of things. They feel and act, well… native! Maybe I just haven't seen enough well executed HTML5 apps, but every one I've used so far is a far cry from what a native app can be. It's often
154.
▲
by
LnxPrgr3
14y ago
Growing up in the US, we're exposed to these units our entire lives. End result? When my GPS tells me to turn right in a quarter mile, I can eyeball that distance. If it told me to turn in 400 meters, it'd make me pause a bit. When I buy a
155.
▲
by
LnxPrgr3
14y ago
I tested under native, but you raise an important point—IIRC I was testing with FreeBSD 7.1, and seeing as 9.0 is out it's definitely worth a retest.
156.
▲
by
LnxPrgr3
14y ago
Why is not knowing things so fashionable these days? Especially in a community of people I'd think would be taking things apart just to learn how they work. > Why should you know how an internal combustion engine works in order to dri
157.
▲
by
LnxPrgr3
14y ago
Erm… I meant FreeBSD and Mac OS X have slower mutexes than Linux. Not sure how that sentence slipped by me.
158.
▲
by
LnxPrgr3
14y ago
A couple nits to pick: (1) Mutex performance isn't constant by OS. My own measurements tell me FreeBSD and Linux are around 20x slower than Linux locking and unlocking a mutex in the uncontended case. (2) Contention makes mutexes a lot slow
159.
▲
by
LnxPrgr3
14y ago
I'm surprised I haven't seen anyone mention this addition to the ToS: "Except if you opt-out or for … 'Excluded Disputes' …, you agree that all disputes between you and Instagram (whether or not such dispute involves a third party) with reg
160.
▲
by
LnxPrgr3
14y ago
Android may be the more popular platform in general, but there sure are an awful lot of iPhones being used to take pictures for Flickr, and apparently not a whole lot of Android phones. The most popular camera on Flickr: the iPhone 4S. Not
161.
▲
by
LnxPrgr3
14y ago
From the link: "The language we proposed also raised question about whether your photos can be part of an advertisement. We do not have plans for anything like this and because of that we’re going to remove the language that raised the ques
162.
▲
by
LnxPrgr3
14y ago
> Better to prototype and iterate. Agreed. Version 1.0 is a glorified prototype anyway. Nothing about writing a spec prevents you from prototyping and iterating, though. These are not competing ideas. Of course you won't get everything
163.
▲
by
LnxPrgr3
14y ago
Did you read the link I posted? The idea is by having a spec, you're more likely to see where it needs to be patched upfront, before delivering poorly designed software to angry customers, so you spend less time re-working it later on. >
164.
▲
by
LnxPrgr3
14y ago
By the time someone writes the software, the business need has already changed. Software doesn't work. What? Since when did specs become immutable? Needs have changed? Patch the spec. It's faster than patching the software. From http://joe
165.
▲
by
LnxPrgr3
14y ago
I searched HN for this story and was surprised to not find it, so I submitted it myself. It was dead within an hour. And really, thinking about it now, it probably deserved to die, just as the Apple story probably deserved to die. The only
166.
▲
by
LnxPrgr3
14y ago
One thing I've found that works for me: stop designing before you've worked out every detail. Leave some design issues unsolved. Just get to where you believe you'll be able to solve them as you code. That way, when you're coding your brain
167.
▲
by
LnxPrgr3
14y ago
People keep saying this, but I'm not sure why. Maybe my experience is warped, but if I had to stereotype I'd say it's younger people walking around with Android phones and older well-off businesspeople walking around with iPhones. I'm not s
168.
▲
by
LnxPrgr3
14y ago
(1) Varnish exists, so we can actually run it and analyze its performance. There's no need for "this can't work because X" arguments because we know whether it can work or not. The author claims Varnish works with huge mappings too. In anot
169.
▲
by
LnxPrgr3
14y ago
"Varnish allocate some virtual memory, it tells the operating system to back this memory with space from a disk file." I'm pretty sure the article's talking specifically about mapping a gigantic file into memory and pretending it's all in R
170.
▲
by
LnxPrgr3
14y ago
Coming from iOS: You still get memory-mapped file I/O. There's no swap file, but you can still map files into virtual memory and the OS can page pieces in and out as necessary. Virtual memory isn't just about swap.
171.
▲
by
LnxPrgr3
14y ago
My experience has been that most programmers are more or less clueless about how virtual memory works. At best, they understand it as letting you swap out memory to disk when memory runs low. Even ignoring Kamp's "mmap the world" approach,
172.
▲
by
LnxPrgr3
14y ago
You might find this interesting: http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf "For all program aspects investigated, the performance variability due to different programmers (as described by the bad/good ratios) is on average
173.
▲
by
LnxPrgr3
14y ago
A big part of me hopes I'm wrong about this. Even if it's not what everyone wants to do for a job, being able to code is incredibly empowering. I was lucky to appreciate that early on. I'm an odd case: I was a really stubborn kid, and I d
174.
▲
by
LnxPrgr3
14y ago
I am all for making good programming instruction available to anyone who wants it. I hate to think lack of access to knowledge and mentors is holding potentially brilliant programmers back. But I'm also sure this isn't going to turn program
175.
▲
by
LnxPrgr3
14y ago
Some of my favorite work has come from me saying "How hard can it be? Screw it… I'm building this myself." Even from the failures I learned a thing or two, and I had a ton of fun at the same time. I for one love being in way over my head. K
176.
▲
by
LnxPrgr3
14y ago
It's said that Lisp programmers often work by first building a domain-specific language for solving their problem, then solving the problem in that new language. Some object-oriented programmers do something similar, where their programs ar
177.
▲
by
LnxPrgr3
14y ago
Somewhat related idea: given an employee who's stellar in some areas and not so stellar in others, do you try to even their attributes out, or do you develop the areas where they're stellar even further? I'm a fan of this line of thought:
178.
▲
by
LnxPrgr3
14y ago
I've had a car catch fire on me, while I was driving it down the Interstate. It was a good old fashioned American V6, too: a Pontiac Bonneville. Was it a sign of a design flaw? Of possible risks with gas vehicles generally? Or was driving d
179.
▲
by
LnxPrgr3
14y ago
Glorified PDP-11 assembler or not, C is still how a lot of work gets done… a lot of the work I find the most exciting, personally, where performance is a critical feature and not something to be left to chance. Not to mention all the low-le
180.
▲
by
LnxPrgr3
14y ago
I've seen people go to extreme lengths to avoid being a victim of overcommitted memory: http://www.baus.net/memory-management Even after having the occasional run-in with the OOM killer and having to drive into work at 3am because sshd wa
More ›