aaronkaplan

Is UI construction inherently that complex, or have we just not found the right programming model yet? Is it unreasonable to wish that sometimes things would just look and work the way I intended on the first try?

The IRI Data Library team curates and provides access to data related to the Earth's climate and its effects on human populations, and builds web applications that present such data in forms that are needed by decision makers at government agencies and NGOs worldwide. Most of our current work is related to agriculture and food security in the developing world.

We're looking for an intermediate-level software developer (3-5 years experience) to help with improving the platform as well as developing applications on that platform for specific projects. Experience with linux system administration/devops, scientific/numerical computing in python, GIS programming, and web application development would all be appreciated.

Apply via https://iri.columbia.edu/contact/employment/ and feel free to drop me a line as well.

The IRI Data Library team curates and provides access to data related to the Earth's climate and its effects on human populations, and builds web applications that present such data in forms that are needed by decision makers at government agencies and NGOs worldwide. Most of our current work is related to agriculture and food security in the developing world.

We're looking for an intermediate-level software developer (3-5 years experience) to help with improving the platform as well as developing applications on that platform for specific projects. Experience with linux system administration/devops, scientific/numerical computing in python, GIS programming, and web application development would all be appreciated.

https://iri.columbia.edu/contact/employment/

The IRI Data Library team curates and provides access to data related to the Earth's climate and its effects on human populations, and builds web applications that present such data in forms that are needed by decision makers at government agencies and NGOs worldwide. Most of our current work is related to agriculture and food security in the developing world.

We're looking for an intermediate-level software developer (3-5 years experience) to help with improving the platform as well as developing applications on that platform for specific projects. Experience with linux system administration/devops, scientific/numerical computing in python, GIS programming, and web application development would all be appreciated.

https://iri.columbia.edu/contact/employment/

The IRI Data Library team curates and provides access to data related to the Earth's climate and its effects on human populations, and builds web applications that present such data in forms that are needed by decision makers at government agencies and NGOs worldwide. Most of our current work is related to agriculture and food security in the developing world.

We're looking for an intermediate-level software developer (3-5 years experience) to help with improving the platform as well as developing applications on that platform for specific projects. Experience with linux system administration/devops, scientific/numerical computing in python, GIS programming, and web application development would all be appreciated.

https://iri.columbia.edu/contact/employment/

The IRI works with stakeholders in developing countries to use climate science and data to improve human well-being. Applications include crop insurance, and planning interventions to fight malaria and locusts.

The IRI Data Library http://iridl.ldeo.columbia.edu is a 25-year old web application that is at the core of most of the institute's work. It's a quirky application written largely from scratch, and primarily in a homegrown dialect of Forth. Our current focus is bringing the application into the 21st century and integrating it with the burgeoning open source geoscience ecosystem, without interrupting ongoing work that depends on the existing platform.

There is an open position with the title Staff Associate III on the Data Library team. Responsibilities include software development and maintenance of the platform, using the platform to develop applications, and training and supporting users. Post-COVID it will involve travel to Africa and South America to help partners install and use the software. https://pa334.peopleadmin.com/postings/6360

Please apply through the annoying HR website. A real person will read your application in short order, I promise. Although the cover letter is optional according to HR, I strongly encourage you to upload one explaining why you're interested in the position and how your experience is relevant. Mention that you saw this on Hacker News. I welcome questions by email as well.

The International Research Institute for Climate and Society (IRI), part of Columbia University's Earth Institute, works with decision makers in developing countries to help them use climate science for the good of their populations, particularly in agriculture and public health (e.g. providing crop insurance, targeting pesticide application to control the spread of locusts). The IRI Data Library is a web application that's used for much of that work. We're looking for a a software developer to help build, maintain, and support the Data Library. There will be travel involved (15%) to install the software and train users in developing countries.

The application is a 25 year old crufty mix of Fortran, C, Perl, JavaScript/jQuery, and a custom dialect of Forth. We're rebuilding it on a new foundation of python/xarray/dask, while continuing to support all the vital work that depends on the existing system.

Minimum qualifications: B.S. and 4 years' experience, web development skills, familiarity with Earth Science datasets.

IRI is located on Columbia's Lamont campus, in a bucolic setting 15 miles up the Hudson River from the city. There's a free shuttle between Lamont and the main campus in Morningside Heights.

As I write this, the opening hasn't been officially posted yet. I'll give an update as soon as it's official. In the meantime, contact me for info.

The International Research Institute on Climate and Society at Columbia University's Earth Institute is looking for a programmer to work on their Data Library. Unfortunately I don't see a way to get a permalink to the job listing; you can find it by going to https://jobs.columbia.edu/ , clicking "SEARCH OPEN POSITIONS" in the left nav, and specifying Department 6061.

I'm not affiliated with the group. I actually interviewed for the position last week, but probably won't end up taking it.

1. Our process went like this: first the researcher wrote up a description of the invention for review by a panel of his peers. If the panel decided that a patent should be filed, then the file was handed off to a patent attorney, who transformed the clearly-written technical description into an incomprehensible mess of legal jargon. The inventor was supposed to review it and confirm that it accurately reflected his invention, but if asked in confidence, I suspect most of the inventors would admit that they didn't understand a word of it and just signed the application to get it off their desks. To reiterate: these things were so bad that the inventor himself didn't understand them.

4. There were conflicting opinions withing the company, but it is true that some people advise against doing a search of existing patents. I'm not an expert in the law, but as I understand it, if it can be shown that you had knowledge of the patent you were infringing, treble damages can be imposed. And in software, if you search hard enough you're sure to find something you're infringing.

I agree with your point -1. Once we had filed a patent, we were free to publish our work in journals and conferences, and these papers were written by the inventor with the intent of communicating, in contrast to the patents, which were written by a lawyer whose intent seemed, as far as I could tell, to be to obfuscate and confuse.

If technical considerations were the only considerations, we would find a way to get at the content directly instead of using this Rube Goldberg mechanism. But of course there are also economic considerations. Content owners don't want to give you unadulterated content for free; their business model requires that ads be served along with it.

Will an arms race develop between scrapers and publishers, similar to the arms race between spammers and spam filters? Will publishers start randomizing their HTML generation, or otherwise making it difficult to separate content from peripheral material?

  <span class='w0'>E</span>
  <span class='w1'>n</span>
  <span class='w2'>t</span>
  <span class='w3'>e</span>
  <span class='w4'>r</span>
  <span class='w5'> </span>
  <span class='w6'>t</span>
  <span class='w7'>e</span>
  <span class='w8'>x</span>
  <span class='w9'>t</span>
  ...

[edit: removed question that was answered by sibling post]

On the other hand, it got more posts than last month's, so maybe I'm wrong.

But aggregators can publish RSS streams too. How is following someone on Twitter different from subscribing to his RSS feed?

I would agree that a site like HN isn't very attractive to read via RSS. When the ranking is dynamically determined by readers' interest, you lose something by freezing the list in the form of an RSS stream. But for a curated site like Slashdot, what difference does it make if the link stream comes in the form of RSS or as tweets?

Incidentally, I wouldn't call HN a curated site. Slashdot has editors/curators; HN doesn't.

- Making a copy of a file isn't stealing because it doesn't deprive anyone else of the good.

- When vendors claim that X pirated units of a product whose retail price is Y amount to X*Y of lost sales, they are full of shit, because this assumes that all the pirates would have bought copies at full price had piracy been prevented.

- If the product were reasonably priced I would buy it, but it's not, so I steal it. This is the argument of the 19 year old in the article, and probably the one you're reacting to, but it's not the same as your straw man. Your straw man says, "it's not stealing," whereas the real person says "yeah, it's stealing, but it's stealing from thieves, so it's morally acceptable."

I don't mean to advance any of these arguments personally, just to point out that they're arguments that some people actually make, unlike the one you so convincingly refute.

Comparing it to your patched F14 version, the roman typefaces look quite different, but overall I can't say I prefer one to the other. The italics, on the other hand, look much better in your version.

There is one strange thing in your F14 screenshot, though--the upper left of the lowercase letter 'a' is straight horizontal, rather than curving down as it does in all the other screenshots, both yours and mine.

Your Ubuntu screenshot looks very similar to your F14 screenshot, but not quite identical: see the dots on the lowercase i, and the above-mentioned problem with the lowercase a.

Thanks!

Is the patch that Legion refers to the same one that's in Ubuntu, or is that something else?

In what applications do you see a difference? I've spent some time looking quite closely at Firefox's font rendering in Fedora vs. Ubuntu and didn't notice any differences.

Wow, way back in 2007? Did you have to enter your programs on punch cards back then? :-)

I use Fedora, and for the past few years it seems like every couple of months an update breaks something, like sound or wifi. Upgrades from one release to another are practically guaranteed to break something. So a while ago when I got a new laptop I installed ubuntu on it instead, hoping that things would be better. But after living with ubuntu for a while I didn't feel like it was any more stable, so I went back to Fedora just because that's what I know best. The vast majority of the bugs I run into are introduced upstream and both distros just pass them along for me to find.

Apt is still faster than yum, and Ubuntu still seems to have somewhat more packages available than Fedora, but Fedora has closed the gap in both areas in recent years. All in all, I don't see a strong argument for either one over the other.

Deltas or no deltas, apt feels significantly faster, but yum isn't slow enough to be a real problem for me.