mvzink

This is exactly why I think Talko is so cool. Not quite a replacement for email, but has some good ideas.

Epsilon-delta proofs are beyond me, but we still teach calculus in high school. Just because some parts of a field are esoteric without study doesn't mean the field is doomed to obscurity.

SEEKING WORK - Seattle or remote

A friend and I recently upped sticks and moved from Chicago to Seattle to put our tech chops to use. We've been consulting together for a little over a year, and I personally have been doing it for one more than that.

Between us, we have experience with a lot of different areas from distributed systems and networking protocols, to, of course, full stack web development. Our main common ground is that we both feel equally at home with C and JavaScript—weird, huh?

Lately, we've been focused on frontend web development and have a lot of experience with Angular in particular. We're quick learners and eager to experiment, but we're also pragmatic and will always choose the right tool for the job. That said, we would especially love to get onboard with a Clojure/ClojureScript project... just saying.

Anyway, if you have a project in need of some love from one or two clever developers, or if you need a solid MVP, shoot me an email: mvzink@isometree.com

SEEKING WORK - Seattle or remote

A friend and I just graduated from the University of Chicago, and decided to put our technical chops to use in Seattle.

Between us, we have experience with a lot of different areas from database implementation, to distributed systems, networking protocols, and of course web development. Our main common ground is that we both feel at home with either C or JavaScript—weird, huh?

Lately, we've been focused on frontend web development and have a lot of experience with Angular in particular. We're quick learners and eager to experiment, but we're also pragmatic and will always choose the right tool for the job.

If you have a project in need of some love from one or two clever developers, or if you need a solid MVP, shoot me an email: mvzink@isometree.com

SEEKING WORK - Remote or Seattle area

For hire: a pair of...

  - Distributed systems theorists
  - Database implementors
  - Web designers
  - JS coders (Angular anyone?)
  - Clojurians
  - Assembl... on second thought, we'd rather not
  - Jacks of useful trades

They seem to approximate with recurrence relations; they cite a bunch of literature about the technique, referring to "cost relations".

The two main inputs to their model are the IR and the ISA.

True. However, as a graduating CS major, almost every non-CS major I know here and at other schools has taken some programming-focused class or done Codecademy or something. Few if any are looking for what we might think of as "tech" jobs, or are motivated primarily by any promise of money. I can anecdotally attest to the fact that all the reasons listed by the author are playing a significant role.

(As a side note, a fair number of the people I know who are doing straight up startup-style "tech" jobs after graduation aren't even CS majors.)

Exciting prospect. How about DataScript for your app state + tx-listen/om-sync mirroring transactions? Might require wrapping the datascript/transact! call, and I haven't thought about reading from the cliente. Maybe as simple as lazily mirroring datascript/q calls and filling those back into the DataScript map.

Funny; the article has me thinking about being more open with our humanity on the web, then you reference an apparent brush with death as a sort of backstory—something many, myself included, would be uncomfortable sharing. Thanks for being candid!

Ideally, in the future, yeah. But for now, two reasons I can think of: first, Multipath TCP doesn't cover the same use cases as dispatch. For example, having one proxy only route to low-latency connections (e.g. for gaming) and another to all connections (e.g. for downloads). Second, Multipath TCP isn't widely implemented and would require application developers to use it, whereas this can give many of the same benefits without waiting for your applications to support it.

It's not designed around global state. It's true that just about every HTTP router has this "feature", but all it's doing is allocating a "global" server object by default and adding the module-level helper functions. In other words, if you only want a single server object and don't need to configure it, or if you just want a quick hello world example, you don't have to allocate the server object yourself. Without those extra convenience methods, this would be hello world's main:

    s := web.NewServer()
    s.Get("/(.*)", hello)
    s.Run("0.0.0.0:9999")

Great article. One thing I wish got more coverage is testing directives: it's already much easier than most DOM-testing methods (though it can't replace selenium etc.), but doing it well and consistently has proven difficult and I don't test most of my directives. For example, I had to modify the triggerHandler function in Angular to allow sending fake key presses since it didn't have a built in way (at least a few months ago) to specify the "which" property on the event.

Also, If you're in Chicago, the Angular meetup group will be talking about testing on November 20th: http://www.meetup.com/AngularJS-Chicago/

This is great news. However, all this discussion of "semantic this-or-that makes my site look like shit" or "semantic tags are just for template clarity" and "well at least web crawlers and Readability can make use of it" is really annoying.

If you think <main> exists to make SEO easier for you, I'm willing to bet that around 7 million blind people in the US alone won't bother trying to use your site. Why? Because their screen reading software won't be able to make it through your mess of markup and get to the part that matters, for one.

It's hard enough getting people to care about accessibility at all, but trying to drive ARIA adoption must be a complete nightmare. <main> is taking one of the most obvious, simple, and useful pieces from ARIA, which just happens to fit in quite sensibly with existing "semantic" tags, and allowing you to remove an important accessibility hurdle without even knowing about ARIA!

I, for one, am extremely glad that I can now make my sites a bit more accessible with almost no extra effort.

I know this is asking a lot, but would anybody like to weigh in with some explanation/evidence for the descriptions of those four parts of the brain?

I actually was going to point out that less saturated colors get... well, maybe not more dramatic, but in-my-opinion-"better" themes. For example, with this one, any but 'complementary' are almost usable http://rriepe.github.io/1pxdeep/#e9ede4

Also, anybody that's using this should be sure to add a rule like

    input { outline: none}

    #change_color { outline: none }

If the explosives machinery did indeed detect permethrin, then they still have a lot to account for. Excuse me if I doubt that a white Christian would have faced the same ordeal and found their home burglarized over insect repellant.

No computer science education or IT experience can save you from the hours of unnecessary struggle that are the real price of a Google Apps account.

Re: siblings and increasing writing skill: there are too many blogs. Try writing in private and for literary (i.e. non-tech) audiences. You'll have better chances of focusing on the actual writing, you'll be able to branch out, you might get feedback on your writing.

I'm really excited to see people working on security in Go. Security by default is supposed to be one of Go's "features" at some level. (The typical example: your first several C programs probably had many buffer overflow vulnerabilities, but it's very likely none of your Go programs ever will.) Still, Go hasn't been very thoroughly tested and security hardened, so I'm hoping to see many more exploits like this discovered and ironed out in the near future.

(Since HN has been in golang hype-mode recently:) a 20-line Go web server that I probably wrote in about 5 minutes but I don't remember because it's still chugging away.

Having written a few web servers (and other servers) in Go, I assure you that you will be surprised how little work it is. However, I think where Go will shine is in highly customizable "frameworks"—not in the vein of Rails etc. at all but rather collections of components you can piece together for your own needs. You can already see how this will look with the net/http library and its Handlers: just about as easy and clear as hooking in Rack or WSGI middleware/apps, but with the safety and holy-mother-of-job speed that you just don't see in Ruby or Python (okay, the speed isn't that big a deal unless you've only been exposed to Ruby...) and without Java's startup times.

    $ go get github.com/person/project

And yes, "go get" comes with the standard gotools.

The thing is, you can do that with interface{} and you don't even need type switching. It's awkward, but considering that the rarity with which interface{} is necessary (at least in my experience), much less interface{} with type switching, I really don't see a big gain in generics. I agree with jff, it seems most people who complain about the lack of generics are those who haven't written much code without generics.

It may be possible to work around that: the trick they use to get full color is that each animation frame is allowed to have its own 256 color palette. So for each block of 256 colors, you have a single animation frame "played" which colors in only that block (the rest is transparent). Hypothetically, the only reason it renders so slowly is that there's a pause between playing each frame.

How could it even go to air? It would be such an incredibly deep and likely harrowing experience that it couldn't possibly be entertaining except perhaps to psychotics—and even if it was funny or something, that in itself would be absolutely horrifying. That said, I would have to see it for its depth and significance.

SEEKING WORK - Chicago - Remote OK

Two friends and I have started a software development consultancy. I still don't know if the freelancer thread is an acceptable place to advertise, but our clients have all been non-tech organizations and I would like to do more work with the HN crowd (it was always a blast in my solo days), which is why I'm posting here.

We are two programmers and a designer primarily doing web development (with a focus on content/marketing and single-page apps), but we have some iOS skill between us and wouldn't be opposed to putting it to use.

We don't have a website up yet (too busy working), but you can email me at mvz@mvz.so to chat.

I would rather see number of processes varied.

SEEKING WORK - Chicago, remote

I've been freelancing/consulting for a while, and this summer I'm joining up with two friends (a designer and programmer) who haven't done any contract work before.

We intend to focus on web development due to common experience, but I have mobile development experience and they are interested in doing mobile as well. We'll be putting up a website soon, but if you want to talk to us ahead of time, shoot me an email: mvz@mvz.so

I'm actually always afraid of this. Since I use Dvorak, should I ever need to log onto a computer with Qwerty, I had better know my actual password—but I'm not sure I do!