Threads for blakef
-
Started feeling wrist pain while working for the first time at the beginning of this week – it’s certainly my fault, I’d developed the habit of using my laptop in bed with pretty poor posture. But I’ll be looking into more ergonomic setups, and will try to take a stab at Talon to see how feasible it might be to replace a lot of my keyboard/mouse use with voice commands.
-
-
-
I have the Freestyle Edge RGB with the tent kit; I’d been on a Model M for my entire life up until that so I wasn’t ready to go full on ortholinear - I actually bought it expecting that I’d hate it and sell it within a couple months. The adaptation period was definitely a thing, and I’m still not as fast as I was on buckling springs, and I don’t think I’ll ever figure out Home/End/etc on this thing without looking at them, but not being in pain at the end of the day really outweighs all of that.
-
-
-
-
I love those kinds of programs! I create aliases and small shell functions all the time in this style. One of my favorites is a
putsfunction that basically evals in Ruby what I type. I often use it to do maths and date calculations. I know you can do this in shell, but I do so much Ruby that it is like a second language (third, after English?) for me.function puts() { ruby -r date -e "puts($*)" } $ puts Date.today + 10 # What day is ten days from now? 2022-03-19 $ puts "10 ** 3 / 9.0" 111.11111111111111-
Very cool ! I always do this by opening a Python shell, but never thought about making a shortcut: thanks :D
-
I just open devtools in the browser, or maybe aa node repl instead, to each their own :)
One of my first utilities that I wrote was a dice, we wanted to play GURPS but didn’t have dice so I wrote one quickly. Back in the nineties there were no cellphones. I’ve written such things before and after but this one i always remember.
-
-
-
To follow the name of Ruby’s method to print to output. You can even see me calling it in the code
puts($*).Also, it not only evals the code, but prints its result.
-
-
I have a similar one:
$ datedate Thursday 2022-03-10 13:09:58 Europe/Stockholm 2022 2022-03-10T13:09:58+01:00 1646914198$ datedate +22 days -1month Friday 2022-03-04 13:10:02 Europe/Stockholm 2022 2022-03-04T13:10:02+01:00 1646395802$ datedate 1646395802 Friday 2022-03-04 13:10:02 Europe/Stockholm 2022 2022-03-04T13:10:02+01:00but since I haven’t found anything as good as php’s strtotime(), it remains the only script that forces me to install php :( Source here: https://github.com/chelmertz/dotfiles/blob/master/bin/datedate
-
A coworker of mine created something like this in Rust:
$ date-math 'dec 30, 2021 + 2 weeks + 1 day' 2022-01-14-
Note that GNU date can do this built-in:
% date -d 'dec 30, 2021 + 2 weeks + 1 day' Fri Jan 14 00:00:00 CET 2022 -
-
-
Maybe https://github.com/hroptatyr/dateutils do the same job without PHP?
-
-
-
-
Maybe a silly question, but is it possible to find mechanical keyboards that other people are happy to work around? Working from home has meant there’s less appetite for keyboard noise.
-
I’ve found it invaluable to building simple UX. It’s perfect for making bash scripts / aliases really pleasant to use, but don’t have enough complexity to warrant writing a python script.
-
We’ve learned that having a function that deletes your database is too dangerous to have lying around. The problem is, you can never really test the safety mechanisms properly, because testing it would mean pointing a gun at the production database.
I’d argue that you should have this function “laying around”, for development use – and it should be the only way you drop and create tables. Otherwise, you’ll fall back to dropping tables by hand, where it is impossible to add more safety. At least with this function you can add checks like “don’t do it if any table has 1000 records” or something. This is called poka yoke.
-
Thank you for sharing the link to poka yoke! I had never heard this expressed in such formal terms, but it makes a lot of sense after it is.
-
-
-
Getting back into my non-technical hobbies. This weekend I intend to continue teaching myself Latin, and finally sit down and plan out a novel that’s been brewing in the back on my mind for a while.
-
-
pragmatic
edited
2 years ago
|
link
| on:
Taking my home work setup seriously: ergonomics and settling in for the long haul
Nice setup.
- I really advice against the side by side monitors. There problem is, your going to have your main app open in one monitor at a time so your going to be turning your neck for hours at a time. Suggest either stacking it going with a single large monitor. I got a Dell 43” 4k monitor for $700 ish. I previously had a single 32” ultra wide, which as the author mentioned is too short. Then a friend sold me his and I stacked them. That was ok but made me standing desk hard to use in standing mode.
I like the single monitors with a window management app. I’d love this setup now if I could get it in a curved version and a higher resolution for sharper text, but otherwise it’s amazing.
- I’m always amazed that people are so hesitant to spend money on their work tools. They are tax-deductible but more importantly, they are in investment in your long term health and happiness. It’s one of the biggest advantages of working from home. Your don’t have to use the cheap crap your employer provides.
It’s doubly amazing because many in this situation are making $100k (possibly multiples of that). Also do many people have some crazy expensive bike,car,boat,guitars, home theater, etc that’s only used a few hours a week.
I know it’s tempting to cheap out, but 30,40,50 year old you will thank you.
That’s my PSA if the day.
-
-
-
-
I don’t know if it’s just about distance. I find the vertical angle matters much more than the horizontal angle. For example, I find laptops difficult to use for long periods because my neck gets sore looking down all the time, instead of looking straight ahead. However, I don’t have any problems with horizontal monitors.
-
-
-
That’s a good point about the dual monitors. I’m considering having one facing flat forward, and another angled off to the side. I’d probably have to sit off to one side of my desk but that’s not too concerning.
I get your point about spending money on work tools, which might fall in the same category as what people say about beds & shoes. I do worry this attitude if adopted too enthusiastically can dull judgement about whether a given tool is really necessary - for example a gas-spring monitor stand instead of a basic one or an Ergodox instead of Goldtouch keyboard (although I admit being tempted by the Kinesis Advantage2 from seeing all the people who swear by it). With the way our society is set up it is often very difficult to determine (even within our own heads) whether something expensive is a reasonable purchase that supports good craftsmanship, or just a flex.
-
-
-
I do this too. The only problem is that 16:9 screens reeally don’t like being in portrait. I have a 24” 16:9 screen to the left of the primary screen used mostly for web browsing, and it’s really common for websites to grow a combination of horizontal scroll bars and buttons with text extending outside of their bounds.
-
Hah, yeah I got the last 16:10 that dell sold a few years ago and just picked up a partner for it, and having them side-by-side vertically is great, but I would be loathe to throw away 10% of that space.
-
-
-
-
All decisions come with error bars. Fall on one side, you have a flex; fall on the other, you are performing worse at work than you could be.
I know which side I’m happier to land on.
-
The main point is this: every single person I’ve had a discussion on buying quality tools for work and had an objection to spending money also had some expensive hobby they were willing to splurge on. (I’m sure not everyone is like this, just seemed the people with the strongest objection had other money sinks). Is just a matter of logical consistently. They might have $25k of bike equipment in the garage but get upity about spending $500 on good equipment. That’s why this is one of my hot button issues. A course of physical therapy is going to cost more than decent equipment.
My old equipment always finds it way to friends and family and tends to get years of useful life beyond me.
-
There’s nothing logically inconsistent about spending money in some places and saving it in others. “I spent a bunch of money on thing X, so I should also spend a lot of money on thing Y” sounds more like sales tactic psychology than logical reasoning. You can easily get good enough ergonomic equipment to keep the PT away without spending much money. A $20 used Microsoft Natural Ergonomic 4000 keyboard, a $25 Anker vertical mouse… even monitor stands can be replaced with a stack of old technical manuals. A good chair is really the only thing I’d say you need, and you can get a good-enough used Costco model for like $60.
-
-
It is if a) this is the way you make your living and b) you are oddly cheap in this area but spend big money on things you use way less. That’s the point in trying to make and I still find the behavior quite baffling.
Invest in yourself and your health.
I’m not trying to sell you a standing desk.
-
-
-
That’s a good point about the dual monitors. I’m considering having one facing flat forward, and another angled off to the side. I’d probably have to sit off to one side of my desk but that’s not too concerning.
At work with a two monitors set-up, I tended to have my main one in front of me flat and the other angled on the left. Not being in the centre of the desk allowed me to have a notebook and pen on the left of the mouse that I can reach for quick notes and having a space not in front of the main screen for thinking with reasonable space to use the notebook.
-
-
-
Working on a new system I’m kind of excited for. We have tens of thousands of JSON files sitting in an AWS S3 bucket that we finally need to put into a relational database. So first is to scrape existing and second is to build a system that is triggered when new JSON documents show up.
-
I haven’t used it personally, but have you looked at aws athena?
EDIT: full disclosure I work at AWS on something completely unrelated.
-
-
-
Heading to Cape Town for the weekend. This should be fun.
-
I don’t do much front end work these days but if I did, I would want a service that hosted all of your images and automatically resized them based on GET parameters, e.g. https://example.com/someimage.png?size=1024x768
I’m sure there are tons of products that can do this but it would also be trivial to roll one’s own. It would be easy to write some sort of step into your deploy or build process that figured out the size of the image needed and generated a URL for it. Or do what all the cool kids are doing these days and just design the whole thing in Javascript anyway.
-
We actually use Cloudinary at work and it does a lot of stuff based on the URL you pass it.
-
-
I work at Imgix, which does some of that: instead of uploading your images to us, we request your images then render them, with heavy caching. Also usable as a JavaScript library.
-
I was responsible for porting some of our existing code at work to use Imgix. It worked great for us, simplifying a whole class of problems that came serving user-generate content. Reasonably powerful API (so dead simple for us to use: all query string driven). I particularly liked how it acts like a proxy, lazy loads and transforms the images.
-
-
It’s trivial, unless you care about performance (for many images).
There’s no mature, open source library for generalised GPU conversion (one of these days)…
Formats are inconsistently supported; third party images may be too large to fit in ram once decompressed (even if the file is small); I’m sure I’ve forgotten a few other issues…
-
In many cases (ok, not all) the site owner uploads the image. You’re not going to deliberately dos your own site with a bajillion pixel png. Caching is trivial, etc.
I don’t think it’s theoretical concerns that prevent this from being more commonplace. It’s just friction and intertia. e.g. bad defaults.
-
-
-
The open source community already has this and it’s called Thumbor
-
-
I’m not thrilled that yet another frontend tool is getting its own plugin ecosystem. I already have Browserify plugins, ESLint plugins, Babel plugins…
-
-
-
-
The biggest drawback with Dart is that the Dart-JS interoperability is pretty poor. It can be done, but it’s ugly and usually kind of slow (there is apparently a plan to improve it this year, but we’ll see). The language itself has had some growing pains. Dart was released before types became cool again, so it was very much designed to be a “types optional” language. For the last few years, however, it’s been moving more and more toward being a regular statically typed language. That transition is finally complete with the release of Dart 2 last summer. At the same time, there is concise syntax for runtime type checks and casts, so it’s reasonably simple to deal with data from JS if you need to. Performance is good, as long as you don’t have to talk to JS code.
As far as tooling goes, it’s pretty great. One solid package manager that everyone uses, one solid unit testing package that everyone uses, one linter that everyone uses, etc. Code generation is straightforward and built into the tool chain if you need it (we use it extensively). Good IDE support (JetBrains, Vim, and VSCode all have good support). The syntax is very similar to modern Java, so any capable developer can become productive in a few hours. Finally, with Flutter becoming popular Dart libraries and skills can be reused on mobile.
I’d be happy to answer other questions.
-
Dart-JS interoperability is pretty poor
You’re talking about using package:js here?
I’d looked at Dart about 2 years ago (read through The Dart Programming Language), and really liked what the language had to offer, but even at that stage TypeScript seemed a more pragmatic choice. The Dart tooling (from what you’ve described) definitely simplifies some of the problems I have with configuring a TS project (many hours lost to configuring webpack, babel, tslint, etc…).
I found Go very attractive precisely because of the uniformity and simplicity of the tooling.
-
You’re talking about using package:js here?
Also
dart:js, which is deprecated IIRC.If I was choosing today, I would very seriously consider TS. The decision would have a lot to do with whether I was going to rely on existing JS libraries that have no good Dart equivalents. If I was planning to do mobile, though, I’d almost certainly go with Dart, Flutter is just fantastic IMO.
-
-
-
-
-
-
Working on a tool to help manage project dependencies, particularly to coordinate branch checkouts on our development machines. I’m sick of working on a branch, checking out one of our backend services and having a runtime error because one of our share libraries is on the wrong branch.
-
The recommended line length in Black is 88 characters.
I’ve participated in a few code standardization processes. By and large I’m an enormous fan: I read a lot of code and am helped by the consistency they promote. Python has particularly been kind to me here with pycodestyle and pylint.
The thing I’ve learned from them though is that I’m the last person on the planet (or at least the three companies I’ve had a hand in standardizing) that still uses an 80-character terminal to code. It’s the one thing I have a (literal) hard line on. I note the nature of the problem often doesn’t get through and so I’m offered compromises that are as equally bad as to the original. I don’t think I’ve ever been offered “how about 88 characters” but I have worked with folk who themselves tell me they won’t tolerate anything less than 100+ but try to talk us somewhere between 81 and 99 characters.
The terminal is 80 characters wide.
-
The terminal is 80 characters wide.
I’m a fan of short lines, but this is a pretty bad argument. What is The Terminal? Even without running a GUI like X11, you can get higher resolutions in framebuffer or whatever it’s called.
IMO, the compelling argument for me for shorter lines is readability. I just can’t read long lines, I got lost and confuse by the end. I like reading down than across.
-
-
The terminal is a VT100, with support for an 80x24 display. The 80 character limit was present before then, however, via the 80-character punched card. Those having 12 lines rather than 24.
It is marvelous that we have a display technology backward compatible with the entire history of computing.
-
I’m not sure I get your argument, though. Because old tech had a width of 80 characters, we should now? Old tech had a clock rate of 100 Mhz and little storage, but I doubt you’d argue we should be using machines with those specs. And the truth is: almost nobody is programming in a VT100 terminal today. So are you making a luddite argument for line length or is there an actual benefit to 80 characters?
-
-
I’m saying that if you have to choose a line length, in a standard, that 80 characters is the choice we already made. As a consequence of that choice, 88 characters is two lines. That if your choice is 80 characters or 88 characters, 80 characters has a superior and sufficient claim to be a standard.
Pep 8: Limit all lines to a maximum of 79 characters.
OpenBSD mailing list netiquette: Plain text, 72 characters per line
It is true that terminal emulators will emulate a display larger than 80 characters. I’m a fan of the -S flag to less when I’d like my input file to tell me how wide my display should be. I also routinely work with two terminals side-by-side on a graphical display. Both modes of working are fantastic. The later is enabled by a standard line length of 80 columns. When my terminal has an 81st column, I’m using that column. It’s not available for use by the standard.
-
-
The other area where the question of line length comes up is typography. There, line length is measured by words rather than characters owing to the proportional spacing of characters in a font. If I was dealing with source code in a typographic context the conventions of that field would also apply–possibly to the exclusion of monospace font conventions, possibly in combination with monospace font conventions, depending on how the code is typeset.
-
-
You’re missing my point, I’m not saying we should change it just to change it, I’m asking why a decision made 50 years ago still applies today. If long lines are uncomfortable to read, that is at least an argument that would still apply today and not simply the momentum of history.
-
-
-
-
-
-
-
-
-
After lobste.rs talked about A Fire in the Deep and A Deepness in the Sky, I just finished reading them. Developments like these make me think of the tech, thousands of years old and completely irreplaceable, that exists in A Deepness in the Sky. On one hand we lambaste the JS world for rewriting itself every other week, but at the same time we keep Java alive and kicking. I am one of those people that thinks the JVM is long past its prime (every heavy use of Java is running it on hardware the have defined ahead of time and don’t benefit from anything the JVM gives them), but I guess we’ll be stuck with Java for a long time as it keeps on doing accreting new functionality to keep chugging a long. IBM posted its first quarter in 5 years where it will see growth. Why? Thanks to the mainframe portion of the business.
-
I am one of those people that thinks the JVM is long past its prime
IIRC, the JVM is an incredibly fast VM with hundreds of man years put into performing well.
That alone ensures it will stick around for quite awhile.
-
-
-
Got a cite for that? I don’t doubt what you say, but I think a lot of people formed impressions about Java that are of varying levels of accuracy.
The fact that companies like Square, Netflix and Amazon use Java extensively even for greenfield projects should be an indicator that Java is far from the tire fire some people make it out to be.
Sure, it’s verbose, and there are parts of its ecosystem that are excessively complicated, but there are newer choices that have learned from the past and eschew that kind of complication in favor of a much leaner style.
I’m not trying to get anyone to love or use Java who doesn’t want to, but I’d encourage people to challenge their long standing impressions and come to a better understanding of what the language is good at and which use cases might call for its use.
-
-
-
Ah,
One source:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=go
The JVM beats Go for 3 out of 10 problems (and by a pretty significant margin).
For Ocaml, it’s 4/10 for beaten by a significant margin, and the other numbers are pretty comparable:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=ocaml
The most common use-cases I see today is server-side, which are almost entirely I/O bound. Erlang compares well to Java in this use case, if only for utilizing I/O so well.
I don’t have any studies for you other than the fact that everything is a service now.
For the complexity aspect of my claim, I think that is self-evident if you’ve looked at the code of the various runtimes.
-
So, thanks for some good food for thought. I’ll leave you with this - Every problem is different. There are still large swaths of problem space that the Go ecosystem has barely even nibbled at which have very rich support in the Java world.
That combined with newer frameworks which are the polar opposite of some of the useless complexity we’ve all battled in the past (Take a look at Play for an example of what I mean) can make Java a really great choice for some problem domains.
I just think we need to be careful about making overly general claims, and open minded to the fact that there are huge swaths of the industry still coding in Java for a reason.
-
I think some aspects of my point are being conflated a bit, though. I’m not making a statement about Java-the-language, I’m making a statement about the runtime. My point about Ocaml/Go, which I didn’t make very well, is really that these are languages with a much simpler runtime but still quite comparable performance combined with my claim that the problem the complex runtime is solving is not a problem a vast majority of Java users have.
I just think we need to be careful about making overly general claims, and open minded to the fact that there are huge swaths of the industry still coding in Java for a reason.
If you reread my first comment, I think you’ll see I fully acknowledge that. Mainframes are still a money-making business (would you advocate one use a mainframe, though?) It’s a fact that people are running lots of workloads on the JVM. I even work for a young hip company that uses the JVM. But I’d also be cautious of reading too much into that, IME, the “reason” people do it is often not connected to a technological merit.
-
Mainframes are still a money-making business (would you advocate one use a mainframe, though?)
That depends. What do you mean by ‘mainframe’? There are scads of business running on the descendant of mainframes - the IBM Power system to this day, running ageless workloads using tools like COBOL and RPG and the like, because those tools suit he use case.
Sure, there are tons of people out there supporting legacy hardware and software nobody in their right mind would choose for a greenfield project, but that’s a different problem.
It’s a fact that people are running lots of workloads on the JVM. I even work for a young hip company that uses the JVM. But I’d also be cautious of reading too much into that, IME, the “reason” people do it is often not connected to a technological merit.
Technical merit has many variables attached. If you’re really talking strictly about runtime size, then you may have a point. I’d argue that for many (most?) people, runtime size is pretty much meaningless.
You’ve successfully proven a couple of assertions like “Go runtimes are smaller than Java’s” and even “under certain circumstances, Go can outperform Java” but I respectfully disagree with the idea that choosing Java might not be the right thing based on technical merit.
-
-
-
-
-
-
-
The JVM exists to be a Java bytecode interpreter. It’s counterproductive to assign any more labels to it – write once, run anywhere is hardly its main focus these days.
I would argue, basing on what most Java software is built for, that the JVM exists to be the best abstract bytecode interpreter there is. It’s not particularly great for small-scale algorithmic benchmarks like the alioth benchmark games, but where it shines is long-running processes. Servers.
The TechEmpower benchmarks demonstrate this. JVM languages occupy a significant portion of the top 10 in every segment.
Comparing the JVM to OCaml/Go runtimes is not fair. The JVM is a much more complicated beast, given that it supports some very advanced features like:
- AOT and JIT evaluation (fair enough, AOT support is experimental, but it is there)
- An extremely sophisticated garbage collector which is user-tuneable (this does not exist in Go/OCaml)
- A user-configurable concurrency model (native threads, fibers, green threads) - OCaml concurrency support is blah and Go only has green threads
- Code hot swapping and dynamic class loading
- Direct native code interface (OCaml is better in this regard, but with Go you need SWIG)
And the new Graal compiler is really cool.
And HotSpot is just one implementation. There are several enterprise-grade JVMs out there that include crazy things like real-time support (PTC Perc, JamaicaVM), AOT (ExcelsiorJET) and native execution (IM3910.
I think your citation of the expiry of the write-once, run-anywhere paradigm is anecdotal. I develop on OSX and run my .jars on Linux and Solaris v11.
As I said, the comparison is not fair. The JVM has about 25 years of engineering behind it. For that reason alone, it is extremely unwise to downplay it as outdated.
-
I don’t really understand the core of your response. Part of my claim is that the JVM is a big complicated beast, and that’s not a good thing. And your response is “It’s not fair to compare it to <X, Y> because the JVM is a big complicated beast”. How is one to argue that being a big complicated beast is not a positive thing?
-
Go and Ocaml are on-par with the JVM in most workloads
That’s a huge benefit of the JVM right there. Most developers and their managers have absolutely no idea what their workloads will be 2 years down the road.
Using the JVM obviates the risk of coming back to a system and having to significantly re-engineer it due to Go’s/OCaml’s runtime starting to choke as the amount of data grows:
Service needed 1GB back then, now it requires 10GB.
- Go/OCaml: Rewrite your application.
- JVM: Who cares? Traffic could even have grown to 100GB, and buying more RAM would fix it.
Using lesser runtimes is basically a bet that your application will never experience an increase in traffic.
-
Your claim that the JVM just magically scales up to any workload does not match my experience. I see software rewritten on the JVM as much as any other language. Perhaps you have some specific experience in mind that you could share. Maybe you’re talking about something like Azul? Sure, I’ll grant you that. But in the microservice world, those situations are few and far between. To be clear, I am not saying that some people aren’t just buying bigger hardware to run their JVM programs, I am saying that usecase is dwindling, IME.
-
Well, you said: “Language implementations like Go and Ocaml are on-par with the JVM in most workloads people care about”.
I pointed out that the Alioth benchmark game is not “most workloads”. I gave the TechEmpower benchmarks as a more relevant benchmark environment (web applications, since that’s what most people do). These benchmarks demostrate that JVM is more performant than the languages you mentioned.
Where you are correct is that the JVM is a complicated beast. I do not disagree there. But it’s a performant and sophisticated one, that is definitely not past its prime.
-
-
-
-
-
The point of the JVM is a portable runtime so you can compile your program once and run it anywhere. However, every company I have worked for deploys their program to one platform, running one OS, in a very well-defined environment. The value of the JVM is limited. “What about the JIT?” one might say, but IME, the JIT offers no value over AOT for modern workloads and it’s significantly more complicated.
-
I do run across projects that make use of the JVM’s non-platform-specific binaries fairly regularly, but for forward compatibility in case of a future platform migration, rather than cross-platform portability of the style where you need to deploy to multiple platforms simultaneously (where, yes, only one platform is usually targeted). It’s not uncommon to find some random ancient .jar file in the
libs/directory, and for the development team to assume that kind of thing is going to keep working forever even if the project migrates to a different platform; there may not even be source, if it was a licensed commercial library. In that respect it has some of the same uses in enterprise as mainframe-style binaries, which also typically compile to some kind of bytecode to ensure binaries will keep running without a recompile, even across major platform updates.-
I’m not sure what part of our industry you’re in but I think those usecases are decreasing over time. I hear horror stories about banks that just have a .jar sitting around without source code that they depend on, but I’m not sure that is motivating enough for why the rest of us have to live with a massively complex runtime.
-
-
-
-
-
-
-
Gladly:
See https://lobste.rs/s/hsdcqo/repo_upon_deep#c_vles2i
Specifically this comment from @akkartik : https://lobste.rs/s/hsdcqo/repo_upon_deep#c_y1nfhu
-
-
-
I think there’s a great deal of truth to that article, in part because I tend to feel that there hasn’t been a meaningful shift in technology since the 70s, when the early iterations of what became the Internet were laid down. The past three decades have been the story of the democratization of technology, not really the invention of new technology. We all carry a supercomputer in our pockets that can talk to anybody else’s supercomputer, but all the pieces of that were already there. We just had to make them small and cheap enough that everyone could have one.
-
In a way, everybody having a “supercomputer” in their pocket hasn’t played out very well, either, and almost demonstrates the anti-intellectualism somebody else mentioned.
A thing I’ve noticed reading some early computer books (like this one by one of the inventors of BASIC)), is that many early computer pioneers expected computer programming (and other computer skills) would grow as computers became more ubiquitous. A person wouldn’t just have a computer, but they’d know how to program it to do simple tasks.
-
I’d love if everyone knew some basic bash or python. Even just basic formulas in excel can teach you something about applying a combination of mathematics, logic and programming to solve a problem. Programming in general is pretty cool and many people don’t even know what they are missing out on while they are consumers checking their Facebook stream for 2 hours each night.
-
-
-
-
Improving our e2e testing on an electron application. The application is a fairly complex Angular application (used to control a DNA sequencer). I’ve written jsonifier, which allows us to (I think elegantly) construct JSON objects for testing. Early stages though.
I always like: talk to me about the last time you got paged into an issue. You can find out a lot about the uglier side of what you’re getting into with 15 minutes and that question as a lead.
“paged”? Last time I carried a pager was nearly 20 years ago. Do you want an answer from the distant past?
Paged is still frequently used in some circles and is tied in and reinforced with the branding of the common PagerDuty product. In my circles, people mostly just say there were called. Some companies have bespoke incident management tools so they say they were XYZ’d where XYZ is some obscure tool. Paging may not translate as well internationally.
And the verb “paging” existed well before pagers were invented. The term is more generic that you seem to be suggesting.
Can confirm I’m from the present. Emoji for proof 😉.