Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
gyepi
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
34 ms
·
91.
▲
by
gyepi
13y ago
I have kept bees in West Africa. In my experience, African bees are a bit more defensive than European bees but they are by no means "killer" bees. Certainly, there is no more risk (from the bees, anyway) to maintaining a bee hive in Africa
92.
▲
by
gyepi
13y ago
I would agree that certain aspects of programming is quite similar to writing. Both require a certain command of the raw materials and good taste and judgement in how to assemble those materials into finished form. The analogy works because
93.
▲
by
gyepi
13y ago
> Your "A-game" is your best, not the best in the world.... Hmm, that doesn't jibe with the idea of not rewarding mere effort, which is how I read it as well; we reward results, and "punish" lack of results. This isn't necessarily a bad
94.
▲
by
gyepi
13y ago
>I think the next time I interview a candidate I will ask them what major open-source libraries they use. Then I will ask them what they think of the quality of the source code Sometimes, it is eye opening to read the source code to som
95.
▲
by
gyepi
13y ago
I have noticed the increasing paucity of documentation in many open source projects. In the past, this would annoy me when I had to context switch from a perfectly good flow state to a documentation reading state. However, I realized that I
96.
▲
by
gyepi
13y ago
For years, I used daemontools (it still runs a bunch of machines) then moved to runit, which follows the same philosophy. Both are excellent tools and have worked extremely well under many different circumstances. Simple tools that do one t
97.
▲
by
gyepi
13y ago
Much of the advice in here is really good and actually applies to men too. It seems obvious to point out that a multidimensional life is richer, but it took me a long time to find out. Family life and personal development are no less impor
98.
▲
by
gyepi
14y ago
Ack is wonderful example of tool use evolution. Before ack, I used grep to find stuff, but each use would frequently require additional options to exclude certain types of files, then coupled with a pipe to filter other stuff, etc, etc. Aft
99.
▲
by
gyepi
14y ago
Hmm, I'd have to disagree with you on that. It is true that JSON processing could reduce raw scalalability in the sense that a query that uses JSON may be slower than one without. However, having JSON processing in the database simplifies q
100.
▲
by
gyepi
14y ago
Jon Bentley has a chapter on this topic in the performance section of Programming Pearls . This is a very useful skill for reasoning about problem boundaries. All too often, our performance estimates are on the order of "fast" and "crazy f
101.
▲
by
gyepi
14y ago
> nginx and haproxy were really close, it's almost not significant enough to say that one is faster or better then the other. But if you look at it from an operations stand point. It's easier to deploy and manage a single nginx server i
102.
▲
by
gyepi
14y ago
FWIW, I use shell mode in emacs most of the time and it happily accepts, and buffers, multiline commands until you hit enter, unlike the terminal.
103.
▲
by
gyepi
14y ago
Actually, you're copying more than a git clone command. That's the point of the posting. Look at the source or paste into a text editor to see it.
104.
▲
by
gyepi
14y ago
Over the years, I constantly remind my manager, clients, an colleagues to bring me in much sooner than they think they need to. When that happens, the problem definitions are much easier and the resulting solution works. Obvious, when you t
105.
▲
by
gyepi
14y ago
> Or organisations being set up in such a way that the technical folk aren't in-play at the point where problem discovery is happening. Or the non-technical folk being assessed on "solution providing" not "problem defining".... and so o
106.
▲
by
gyepi
14y ago
Most programmers are, I think, quite capable of designing and building software to a set of specifications. However, most would not, in the process, also try to think of all the ways in which users and attackers would try to break their sof
107.
▲
by
gyepi
14y ago
>By going this way you're running towards a brick wall, the wall of your limited brainpower: at one point you will not have enough brainpower to keep juggling the increasing number of "proper tools" and you'll have to stop growing, stop
108.
▲
by
gyepi
14y ago
This line of reasoning is quite standard, and for many purposes, quite valid. However, in my particular case, it is not. Each language served a specific purpose that could have been accomplished by another, but with greater effort. Sometime
109.
▲
by
gyepi
14y ago
Free is fine, but this book is worth acquiring in paper. I have both editions and cannot recommend it enough. If you are responsible for the security of any kind of system and have not read this book you may want to fix that asap.
110.
▲
by
gyepi
14y ago
It's scary because, knowing only one language means that he can only think about, and express solutions to, any problems in terms of that language. In this case, he was not expert at Perl either, so the net result was ... not good. I rememb
111.
▲
by
gyepi
14y ago
Given that the circumstances differ, I don't think I could provide any specific guidelines. I am not averse to using multiple languages in a project if each serves a need so, in the past two months, I have used gsl, TCL, Python, C, and Go f
112.
▲
by
gyepi
14y ago
> See George Lakoff and Mark Johnson’s 1980 book, Metaphors We Live By I highly recommend this book! You'll find yourself nodding in agreement at one line and then realizing that you're agreeing with a deeper truth than you knew. At the
113.
▲
by
gyepi
14y ago
Many years ago, I was working with a Perl programmer and, making conversation over a lunch or coffee break, I asked him what other languages he knew. He replied, "only Perl." I was shocked and persisted in my questioning, even offering up o
114.
▲
by
gyepi
14y ago
AAVE is indeed spoken by people of low economic status, but is certainly not limited to them. I have met many, many African-Americans of high economic status who also do so, but informally and generally only with other African-Americans. I
115.
▲
by
gyepi
14y ago
This is a good question. I've worked in a lot of different domains and can tell you that: 1. They all have boring parts 2. They all have interesting parts. 3. Doing the interesting parts well can be very challenging. CRUD is only boring b
116.
▲
by
gyepi
14y ago
Sorry, but I don't think there's a distinction to be made, other than one of degree unless the implication is that improving government/military processes is not aligned with the long term goals of the military.
117.
▲
by
gyepi
14y ago
I always enjoy finding out how others work. Mostly for curiosity, but also to glean new methods and habits I could adapt for myself. I particularly enjoyed this one because fogus seems to share my habits of using a pen/pencil as a thinking
118.
▲
by
gyepi
14y ago
> If your project sports auto-generated code, or any sort of > build targets that depend on inputs only known after > generation -- Make simply cannot handle this. > There are ugly workarounds but they don't work well. Hmm.
119.
▲
by
gyepi
14y ago
I've noticed quite a few responses in this vein. It may be worth considering that indeed, personal productivity is part of the benefit people get out of this kind of work. I, too, am much more productive working at home. So much so that I s
120.
▲
by
gyepi
14y ago
yes
More ›