4,590 karma · joined November 8, 2014
I don't suppose it's feasible for the Patent Office to crowdsource the examination process: patent applications aren't public. But they could surely hire some people, or a company or two, to use the 'toobz to look for prior art.
Sometime in the next few years, power grid vendors will start to understand they're in the real-time information business.
My brother the archaelogical archivist of ancient (~2000 years BCE) mesopotamian artifacts has a lot to say about archival formats. His raw material is mostly fired clay tablets. Those archives keep working, partially, even if broken. That's good, because many of them are in fact broken when found.
But their ordering and other metadata about where they were found is written in archaeologists' notebooks, and many of those notebooks are now over a century old. Paper deteriorates. If a lost flake of paper from a page in the notebook rendered the whole notebook useless, that would be a disastrous outcome for that archive.
A decade ago I suggested digitizing the notebooks and storing the bits on CD-ROMs. He laughed, saying "we don't know enough about the long-term viability of CD-ROMs and their readers."
Now, when they get around it it, they're digitizing the notebooks and storing them on PDFs on backed-up RAID10 volumes. But they're also printing them on acid-free paper and putting them with the originals in the vaults where they store old books.
My point: planning for centuries long archiving is difficult. Formats with redundancy, at least with forward error correction codes, are very helpful. Formats that can be rendered useless by a few bit-flips, not so much.
Why, oh why, doesn't high-end project management training include case studies of mission-critical systems in large long-lived organizations? Large === hundreds of thousands of people affected. Long-lived === centuries. I'm thinking of, for example, the signaling systems in the New York City subways. You get the idea.
You can't just delete and replace a big system like that like you can a malfunctioning virtual machine at a cloud provider. You have to work with what you have. And, a decade out, you'll still have to work with what you had back then, just less of it.
Any gang of $200/hr fresh-out-of-school devs can do a greenfield system. But maintenance is hard. Upgrading existing business processes without disrupting the business is hard.
In health care, EPIC seems be able (mostly) to do that. Peoplesoft. We don't hear from the govt much, but Social Security seems to be doing it.
What track record of successful business process upgrades do the big-four contractors have? That would be the question to ask.
It's an idea. Not a budget request. Let's not blow it out of proportion.
Hospital visitors and staff should never use patient toilets, ever.
Patients should use their own toilets only.
Staff gets clean scrubs after any visit to a toilet, helping a patient or on their own behalf. Yeah, sterile workers (surgery, etc) have to scrub in again after a bathroom break.
Clean patient bathrooms, including toilets, often, especially if infectious disease is present.
Design facilities to minimize the need to share bathrooms.
"Employees must wash hands before returning to work."
For what it's worth, hospitals already try to do this stuff.
https://kermitproject.org/utf8.html
Handy if you want to make sure stuff works RTL .
אני יכול לאכול זכוכית וזה לא מזיק לי
But don't try it at home :-).
I wonder whether graphene, itself a flat carbon compound, has the same affinity for DNA?
That being said, Markdown + git are a really nice combination.
May your mind be focused and your sitting-upon body parts be made of iron.
So, I got an idea, Zuck! Move to the metaverse! Sell us expensive VR headsets tied to your services. That way we can go online and virtually harass each other in person (virtually). It'll be fun! It'll be bigger than Facebook! Go for it.
Highly intense high-pay professional jobs (oncologist, software developer, bond trader) don't have the sabbaticals baked in. Those of us with that kind of job have to cope with burnout on our own. There's no well-meaning dean or bishop saying, "go take a sabbatical. I want to see a five-paragraph paper describing the insides of your eyelids. It's due in three months. Getouddahere! Go! Now!"
Nobody's going to do it for us. We have to do it for ourselves.
You say you don't want to let your team down. That's great. Keep in mind that they don't want to let you down either. So trust your team members to keep doing what they do, but without your presence for a few weeks. Talk to some of them about it.
Then talk to your managment / front office about it. Come to that conversation with a tentative plan. Say something like this.
"I am fried. I propose to take six weeks off and go snorkeling in the tropics / cut my grass with scissors / build a bicycle of bamboo and ride it to Taos NM / whatever.
"Joey and Anne know what needs to be done in the farkle and framis modules, and they're well-respected by the rest of the team. I know this team; I'm confident they'll continue to do great things while I take the break I need to take.
"What do you think of this plan, boss? Is it workable? Would any changes make it workable for you?"
That opens the conversation in a respectful way. Good managers will probably see how the company benefits ... give responsibility to more people ... keep you "in the socket" even if you're powered down for a while ... build a reputation as an employer with respect and compassion.
If your proposal angers your boss or starts a riot in the executive washroom, well, then you know that about your company as you consider your next options.
A blunter way of putting this is "Always work yourself out of any job you hold. It's the only way you'll be able to do anything new."
That presents quite a threat profile. It's far more pernicious than SEO script kiddles doing whatever passes for keyword stuffing in 2022.
I hope the search crawler folks at Google are working hard to detect that sort of thing and prevent it from getting into indexes. Let's hope Neal Stephenson isn't as right about that threat as Arthur C. Clarke was about geosynchronous communications satellites.
Take risks: tackle projects and subjects where you might not succeed. They are FAR more important to your future than getting super-high marks.
Spend time practicing clear communications. Take a class where a professor guides you in the art of writing clearly and compellingly. If you have the chance, take a class in clear and compelling speaking. Read at least some of Aristotle's Rhetoric. Close friendships help with this: you'll have fun in the time-honored tradition of students' friendly debates in taverns.
If you go into the electronic games industry, do so with your eyes open. The talent pool for that industry is broad and very shallow -- many gaming fans hope to create games. The executives know that, and they shamelessly exploit it. If you go into gaming you want to end up an executive, not just another burned-out developer. (Successful executives communicate very well.)
Sex, drugs, and rock'n'roll are good, but not if they take over your whole life. So, be careful and don't forget that alcohol is addictive.
Above all, have fun doing what you love.
So, every time I get the lat/lon order wrong around here. I get a brief trip to Antarctica.
It's important when hacking this kind of data (or any data) to develop at least some sense for what it means. If there's an error in the data, you want to be able to think, wait, that isn't right, that's in the Atlantic someplace east of Cape Hatteras (or whatever).
And, of course, when using map products like USGS quads or UK Ordnance Survey maps we use those mapping agencies' coordinate systems, be they US State Plane projects, Universal Transverse Mercator, or whatever.
I inherited one app for USA use where the original developer decided the longitude values should be positive rather than negative. Wait, what? Kazakhstan? Must be wrong.
Like any physical measurement, lat/lon makes some kind of physical sense. Unlike many measurements, lat/lon has some constraints. For example you know a priori a latitude of +130° is bogus.
During the first dotcom bubble back in the 1990s, the colocation companies (predecessors to today's cloud companies) sold bandwith based on peak bandwidth usage. It was called the 95/5 plan. It worked like this. They measured my egress data and stored it for every five minutes in the month. At the end of the month they'd calculate the 95th percentile of all those five-minute measurements and then charge me for that.
In other words, I paid for peak egress. Now AWS just bills US$0.09 per gigabyte. Their billing algorithm doesn't care about my peak load. And I have to pay just as much for the rest of the year as I would pay on Cyber Monday, when Amazon's bandwidth is spoken for by their own servers. That's a dislocation.
Lots of stuff works that way. Electricity, water, sewer, highway tolls.
Regulated monopoly electric grid operators traditionally get their rates set as a percentage of the value of their accumulated capital physical plant: turbines, poles, cables, transformers, switches, the land they sit on, and all that. Part of that cost is fixed, but most of it varies with the amount of power they sell.
Net billing for domestic solar electric panels isn't fair to the electric grid operator. When I connect to them on a net-zero tariff, I basically get 100%-efficient power storage for free. They're my battery, and a fine battery they are.
The local grid has an excellent pumped-storage hydroelectric rig. It's about 70% efficient, and it's about 70 miles from here. Shouldn't I pay something for all that if I use it? (The Northfield Mountain storage facility was originally built to store the Vermont Yankee nuclear plant's overnight output for peak load, and it outlasted the nuclear plant.)
They upgraded everybody from utf8 to utf8mb4 (excluding some users of ancient versions of MySQL) with their version 4.2. It went live on April 23, 2015.
They announced the upgrade at the beginning of April 2015 here. https://make.wordpress.org/core/2015/04/02/the-utf8mb4-upgra... There's some interesting stuff in there about the practical difficulties of the upgrade. The biggest issue was, and still is, the need for prefix indexes.
With respect to Adam Hooper, his article was stale when it appeared just over a year after the WordPress schema upgrade. Here's right of course. But the biggest user base was well on their way to abandoning utfmb3 by that time.
True. Demonstrable in the health-care IT world. Think of electronic health records. My personal portable electronic health record would either be a bunch of images of scrawled notes and maybe some nice medical images ( = nonsemantic web) Or it would be in a highly wrought format, i dunno, XML or something, with carefully worked out schemata for everything from flu shot records to heart transplants (= semantic web).
Back in 2007-2010, "electronic health records" EHR were spottily and sloppily implemented by some providers. But, in the US, a federal law pushed more widespread implemetation. Now my online EHR, and yours, is decidedly app-mediated and non-semantic, on a web site portal. Export to JSON? Hah. No.
The hospitals and health care systems only did it because of incentives.
I happened to work at a B2B SaaS company focused on making connections between hospitals and rehab/skilled nursing providers. A rehab outfit can't decide to accept a patient without seeing her medical records and doctors' orders. So our customers had a real incentive to be able to share records. It worked. But the data we had access to (go read about HL7) was not even close to semantic. And our SQL database schemas were, umm, quinquiremes of Nineveh, really intricate, somewhat brittle. Let's leave privacy issues out of the conversation for a moment. Publishing the schema and accepting random queries would help NOBODY except some partner outfit willing to develop and test useful stuff.
Hey, I got an idea! Let's give them an API! Oh, wait, nobody wants to bother with an API? OK, how about a nice web site! And we're back where we started.
With a universal semantic web, the same problems would crop up everywhere.
Any video production goes through a lot of steps from raw studio footage to edited, finished product. This web site says that Netflix processes and people handle a lot of that.
Also it looks like 4K is their minimum standard now. I bet the higher resolution makes it easier, with big*ss GPUs to clean up the raw footage.
(Footage? WTF? Video measured by distance? Maybe we should say "frameage" or "pix.")
Consider the long term. Your uni work will take you roughly half a decade to get through, maybe a little less if you hustle. Your career will last roughly half a century, maybe more if human life spans continue to increase. Take advantage of your uni time to explore as many parts of the world of thought as you possibly can. Take risks. After you leave uni, noboby will care that you got somewhat low marks in that strange particle-physics (or whatever) class you signed up for.
This sounds trite, but it isn't: learn to learn. If you work in our trade (or any knowledge-based trade) you'll be learning for your entire life. You'll choose your jobs and assignments based on how much you can learn from them. Build your skills at extracting value from books and deciding which parts of them deserve a lot of your time and which don't.
One of the best ways to learn is to teach. Think of every assignment and problem set as an opportunity to teach somebody something. Every bit of work you do is an opportunity to teach. By "work" I mean creating things like documents, drawings, code, and so forth. Get in the habit of making things that are, at least potentially, useful to other people and to your future self. And when you gain enough knowledge in particular things, seek out opportunities to explain them to other people. Surround yourself with people who have the same attitude.
Get in the habit of prioritizing your work. You'll always have more to do than you can finish, so learn what to blow off. At the beginning of every uni term, take time to go through the schedules and syllabi for your classes and projects. Start by extracting the due dates for projects and putting them into a to-do list that works for you. Use a calendar app, or an electronic to-do list, or even a sheet of paper you can stick to a wall. That will get you started on planning and prioritizing. And, it will help you avoid nasty surprises like "oh no, I have a final exam in differential equations on the same day my project is due. And that day is tomorrow!!!"
Friendships and romances? Of course. Sex, drugs, rock-n-roll? Of course. Clubs, adventures, sports? Of course. Have fun. I joined a cycling club where we learned together how to work on bikes and took epic trips. But don't waste your uni years by overdoing those sorts of things.
All the best to you!
Hah! Not so.
I've been a dev for a long time, and my spouse a lawyer. Back when we were both fresh out of school I remember running her through quiz questions to help her prepare for her bar exam. We devs HAVE NO IDEA how much arcane archaic stuff lawyers have to pretend to know to get certified to do their jobs.
For example: "mortmain" (French for "dead hand"). What happens when property is bequeathed to a defunct institution? It's on the test. It's easy to come up with a logical answer. But to pass the bar exam would-be lawyers have to know the right answer, cold without looking it up, and why it's the right answer. Hint: it's not at all logical. And, will a working lawyer deal with that question? Maybe three times in her career if she's an estates-and-trusts specialist.
There are thousands of these things for lawyers.
Bar exams are hard because of protectionism -- low supply means high pay. The same is true of doctors and developers. Developer pay is high BECAUSE the exams are hard. The exams are hard BECAUSE developers want high pay.
There's a thing out there called "net promoter score." That's when somebody asks you "would you recommend our business to a friend?" It's based on a 2006 business book with the megalomaniacal title "The Ultimate Question." https://www.worldcat.org/title/ultimate-question-driving-goo...
In theory it's a great idea. In theory it effectively captures a user's attitude toward the businesss. Its inventor, Enterprise Rent A Car, used it to up their game in a competitive market requiring lots of personal service, and it worked brilliantly for them.
But, now the people deploying it in megacorps must have all gotten C- grades in business school. They use it to measure their SUPPORT REPS, not their BUSINESSES. They pretty much only ask it after a support call. So if you give a NO answer to the question because you're frustrated and needed support, the support rep gets dinged, not the product manager.
By the way, anything below a 9 on the 0 - 10 scale in the question means "NO, I would not recommend."
I once got one of those quizzes from my local ISP monopoly provider (Comcast) after somebody CALLED ME to try to sell me something. My answer: "Would I recommend you to a friend? You're a MONOPOLY! " Anyway, they punished the telesales guy for my NO answer. They should have punished the idiot who thought it was an appropriate way for a monopoly to measure customer satisfaction.
A plea to the people who run businesses: take those NO answers seriously. Use them to look for opportunities to improve, not opportunities to punish.
And it is indeed a very high rate.
The insurance guy was civilized enough not to complain that his company's incurring lots of losses -- getting hammered by writing lots of checks to survivors. But surely that's how an insurance company knows what's going on.
It makes no sense for an executive of a mutual insurance company to sling bs about this kind of loss. Because auditors.
It's an important step in the development of your career to understand this about yourself. And, you've been lucky to learn it relatively painlessly by going through this acquisition.
When you go to work at this place, put on your anthropologist hat. Observe what you see happening, and observe your reactions. By all means talk to your supervisors and colleagues about it. But don't gripe, learn. Think like a visitor to a strange land.
This would help countless people new to development. Lots of systems (I'm looking at you, Java) throw up vast splats of tracebacks. Others chunder out great chunks of poorly digested code. Sometimes daunting even for experienced people.
An article with basic advice about looking for the one or two useful lines in error messages would be great.