zoips
zoips on Hacker News
I think you misunderstand. What I meant to convey is that I believe adding filler weakens her already valid point.
Some of those try much too hard, which is kind of silly because you don't need to reach very hard to find people saying stupid/ignorant things about any race/religion/sex/gender/orientation/whatever.
"Most girls aren’t into this kind of stuff." - Easily can be said about guys. In fact, most guys aren't into many stereotypical nerd pursuits.
"How did you learn to do all this?!" - Said to me all the time, and I'm a guy.
"Let me know when you want to do that so I can help you. No offense, but you just don’t know enough about it to try it on your own." - Said to me, and I'm a guy.
"See, that’s the great thing about you, I know I can tell ‘offensive’ jokes around you and you won’t care." - Coworkers say things that make me uncomfortable as well, and I'm a guy (I get squicked out when people start comparing how physically attractive people are, male or female, for example).
The problem is that the general public is going to take "unbreakable encryption" at face value. So don't worry, unbreakable encryption prevents the hacker from getting access to the golden key, because without the golden key even the government can't break into things. The whole thing feeds on itself.
The post was a riff on the standard "One weird trick that [does something] discovered by [quirky, unexpected source]" ads you see.
Which is too bad. I'm curious about rtc's argument around machines taking the pictures. It seems the logical conclusion of his argument is that if you buy a camera, and the software on the camera takes a picture without the act of camera owner, then the owner of the camera doesn't own the copyright but instead the company that made the camera? That seems like a very strange conclusion.
Other way around: opting out will cost extra.
Q contains some helper functions for creating generators, tying them to a promise, and automatically starting the generator, eg Q.async(). I've found that I'd rather continue using Q and use Q.async()/Q.spawn() rather than dealing directly with the generators and managing them.
Have you ever worked at Amazon? He did. For 3 years (I did for 4). I very much doubt PA is any worse than Amazon with regards to it being the job from hell. Everything in the PA job description is practically a carbon copy of what should be in every job description from Amazon.
"he probably has no idea what a market salary looks like"
Amazon doesn't pay as well as Google, but Amazon salary is really far better than you'll get at anything other than the four big tech companies for a normal SDE.
You're conflating their target functions. etcd is all about configuration distribution. Serf seems more like its about member discovery. So you might have a service you run in multiple clusters. Each cluster has a different configuration (etcd), and each instance in a cluster needs to know about the others in the same cluster because they talk to each other (Serf). You could make etcd handle all this, but it probably wouldn't do it as well (Serf has heart beats and recognizes dead nodes, etcd won't do that except for etcd nodes themselves).
No, you're just missing the point. People are focused on the profit and monetary cost of decisions based on their limited capacity to reason about time, which is on the order of probably 10-30 years (if we're being overly generous).
Reiterating, not putting all our eggs in one basket ie self-sustaining human populations not on Earth in the shortish term, not in our solar system in the less shortish term, and not in our galaxy in the longish term, is not something a single person is going to do in their lifetime. It may take (tens/hundreds of) thousands of years to accomplish these goals, if they are even possible, but we should start them now because the alternative is a random case of bad luck with a meteor, or a nutter with a thermonuclear or biological weapon, or whatever. Extinction events.
People struggle to see beyond their own needs and desires. If we're to survive as a species, we have to think and plan on time scales that dwarf the current recorded human history.
This isn't meant to be an indictment of you personally, I'm just pointing out that the view-point, though normal and held by the majority of people, is still short-sighted by definition: a human lifetime is nothing in comparison to human history, and the potential human future.
This is a relatively short-sighted view, and the problems with it can be summarized with two very glib statements:
1.) Don't shit where you sleep.
2.) Don't put all your eggs in one basket.
As a species we really ought to stop doing both of those...
They haven't reached them, that much is obvious since Lua is every bit as dynamic as Javascript and LuaJIT is orders of magnitude faster than V8.
If Google was only interested in putting a faster language into Chrome they could have just shipped with LuaJIT for Lua and been done with it. Obviously they're more interested in playing around in their own sandbox (Dart).
I don't think there's a reason to bake futures/promises into the language. Once you've got coroutines (generators here), people can build the abstractions around them that they like.
That's a pretty terrible way to share code. Simple example: I work on a project, write some code. Turns out that code is useful for someone else, so they reach in and include it, which is easy since it's all the same repo and all delivered to the build system. Now I make a change and break some customer I didn't even know exists. Oops.
This is what package systems are for.
Harmony will include generators, which are basically coroutines.
> Very common problem: interviewers asking questions about who was going to take care of the kids.
Not to excuse this, but it made me think of a rather terrible mistake I recently made, which I am glad has not come back to bite me. I was the last interviewer for a guy who was Jewish and didn't use technology on the Sabbath. As I was walking him back to the lobby I mused out loud that that was interesting since we have pager duty and I wonder what other teams do in that situation, since surely we wouldn't be the only team at the company who employed someone with that or similar restrictions. It wasn't until my wife pointed out to me that that was probably completely illegal and could have had serious repercussions for me that I thought I had done anything but muse about something meaningless out loud.
Sometimes people just don't think, I guess is my point.
Node is marketed towards people with Javascript experience to a large degree, it seems to me (I could be wrong). People with Javascript experience more than likely have it via writing for a browser. A browser functions functions identically to Node: the event loop. So, those coming from writing Javascript in a browser will merely carry through their knowledge of development practices to Node, meaning they intrinsically will write event based code.
Or at least that line of thought makes sense to me.
This is great, but I'd rather not use a fork of Node, and Joyent isn't going to integrate this, unfortunately. I wish that Google would just add yield to V8, but they won't do that unless Apple adds it to whatever the hell their interpreter is called now (Squirrelfish?).
I do like that parsing the claims and determining what is being described is actually harder than designing the system from scratch when you actually finally figure out what the hell the patent is actually about.
I think that misses the point of useful loaders like RequireJS or Dojo's loader. The point of those to enable developers to actually design a modular system with well thought out and declared dependencies. Without them you end up designing a system that is wholly dependent on global namespace pollution and undeclared dependencies. The fact that you get async load is almost entirely irrelevant and focusing on it screams of premature optimization (aka fail).
I'd argue that that would be a really bad idea. You can't be a good software engineer without having a good grasp of Computer Science.
I'm a bit confused about how a web app doesn't infringe. Your claim is it doesn't because it's split between two machines, but that's merely a function of one use. A web app can be used from a single machine, with the server portion and the client portion executing on the same processor. You could even jerry-rig it so the browser and the server communicated via a shared memory map, if using the same memory locations is an issue.
A wiki seems to be a pretty good example. A wiki processor parses data (text) looking for "structures in the data" (camel-cased words), which it then converts to a UI element (hyperlink) that a user can take action on (click it to cause the browser to transition to a new page). At first glance to me it appears wikis violate this patent, so if you can show a wiki as prior art, the patent can't hold.
http://wiki.ecmascript.org/doku.php?id=harmony:proxiesProxies, which are only supported currently in Firefox but should see support in other browsers eventually, will allow you to intercept all types of property access/manipulation on objects. This will allow generalized multiple inheritance and dynamic mixins; I wrote basically that using node-proxy for Node.js.
I wrote a simple library based off of Crockford's writings to make creating reusable constructor functions that supported public/protected/private simple (and without resorting to silly "if it's preceded with an underscore don't touch it!" business). It was written mainly with Node.js in mind, but you could strip out the CommonJS package stuff and use it that way.
https://github.com/zoips/Gizmo