saidajigumi
Joined 14 years ago
Karma
5,163
Submissions
783
Member since
Aug 17
Recent submissions
Comment · 4 years ago
Comment · 4 years ago
There were a few TV models a couple of years ago that would stop working after enough time without a network connection. When they reconnect, they're clearly going to download a new cache of ads and transmit their existing tracking data.
Not quite as bad as that, but since I took my Sony TV offline it regularly reboots itself (when "off") and sometimes needs a "hard" start via the physical power button as the remote on has become unresponsive. I strongly suspect that it's just badly coded, going mad trying to connect to resources that don't exist, filling logs, etc. then failing over.
I so want tracked advertising in all of its forms to be outlawed.
Comment · 4 years ago
This is precisely what the linked article says. From the section "Charging Incentives":
“And it’s not just California and Western states. All states may need to rethink electricity pricing structures as their EV charging needs increase and their grid changes,” added Powell, who recently took a postdoctoral research position at ETH Zurich.
The article also includes other interesting and more nuanced policy details than just "change pricing structure", such as:
Another issue with electricity pricing design is charging commercial and industrial customers big fees based on their peak electricity use. This can disincentivize employers from installing chargers, especially once half or more of their employees have EVs. [...]
So yes, there are weird red herrings in this thread from people who want a technology first and a solution second (or never) and/or who don't understand design of incentive structures. But this work doesn't appear suffer from those problems.
Comment · 4 years ago
To a large extent, I think this is the nigh-inevitable outcome of the corporate world's entire take on open source. Open source has been a hugely successful way of distributing code cost centers, which is how we got here. Yet as many have noted, there's no social or economic model for supporting that work much less paying down its tech debt. Beyond a few Major Frameworks with substantial corporate backing, it's pretty grim.
As an aside, I'm not about to blame folks who came up through bootcamps. I've known too many outstanding devs from those backgrounds, and it's clearly enabled many solid devs to enter the field who would otherwise have been excluded. (I've also met a lot of folks with CS degrees who could give fck all about critical code infrastructure concerns.)
Likewise, for decades we've been striving to build languages, platforms, and tools that support powerful abstraction and code reuse. Somewhat amazingly to me, we've realized some of those goals. So I think the problem also isn't devs working at "glue code" level – at some point we must* work at higher abstractions to get useful work done. Reinventing the wheel (or $datastructure) gets old. Again, I'd return to noting that the foundations are rotten, and the age-old bugbear of complexity management has only gotten worse.
Comment · 4 years ago
As a software rather than keyboard hack, I've been using and loving the following setup on macOS:
* Remap Caps Lock to Ctrl
* Then use Hammerspoon[1] to map Ctrl(hold) / Esc (momentary press)
This essentially puts both Ctrl and Esc in a comfortable position on the home row, probably my favorite "ergo hack" ever.
Comment · 4 years ago
Agreed. Thiago's introductory PARA writings do seem to imply a strict deadline, but like the parent, I use a concrete definition of completion ("completability") as the defining characteristic of a project. If I can't do this, then it's a major red flag and there's some deeper problem and the thing either isn't a project (e.g. it's an "Area" - something you to want to maintain a standard on over time) or it's not well defined enough yet and there's prior work needed.
Case study: Frederico Vittici of MacStories recently wrote about revising his own system to eliminate deadline times from his system as unnecessary overhead that he'd picked up long ago. It was a case of an item from "someone else's system" which was adding stress for no benefit.
All organizational systems are really custom-fit jobs. Look at others' systems and understand the individual techniques and how they fit together. Then apply those to your situation. This is a bit like the advice to not just take someone's complicated dotfile setup (vim, shell, etc.) and add it to your own wholesale. Instead to learn and apply piece-by-piece, understanding that sometimes several pieces must "go in together" to make everything work as intended. (this also applies 100% to every single software team's process in my entire career, btw.)
Comment · 4 years ago
And likewise, this theme shows up in Tom DeMarco's classic book Slack, which contrasts "efficiency" (the rate at which an organization is moveing towards some goal) vs "effectiveness" (the ability of the organization to choose and steer towards better goals). An important theme of the book is that an organization running full-tilt (maximum "efficiency") intrinsically reduces/eliminates its needed human "slack" to reflect and iterate towards the correct goals. DeMarco also digs into into the many organizational and management anti-patterns, with supporting research, that harm both effectiveness and efficiency (and just plain human well being...)
Comment · 5 years ago
Inkjet printers are fine, so long as you don't need or buy the terrible low-end consumer offerings. As an occasional-use around the house printer, I agree they're absolutely terrible, even without the scammy behavior of virtually every manufacturer. Just inkjet head clogging alone is enough to put anyone off. Inexpensive laser printers have been cheaper, more reliable, and much faster for a decade or more. Pay a bit more these days and you get a nice color laser printer with duplex printing. It's worth noting that even low-end lasers aren't immune to scammy behavior. Manufacturers have pulled sleazy tricks like hard page counts for the toner cartridges, so that even if the cart is still good it won't print. At least in the past, there are often embarrassingly easy workarounds (e.g. a minute to Google, then another minute with a sharpie).
That said, once you get up into the (semi-)pro photo/art printers, they're fantastic for that application. i.e. very much not an office printer. The ink per ml in the bigger cart sizes is often one or more orders of magnitude cheaper. You still need to run them enough to keep the heads nice and clean, but they also usually have decent auto-cleaning support built in to help maintain the print head so long as it's getting used periodically.
Comment · 5 years ago
Because the relevant legislation was crafted by those who fundamentally do not understand how the web (or computers) work. The relevant parts of the GDPR should always have described a protocol where the browser acts as an agent on behalf of the user to declare privacy intent.
Comment · 5 years ago
Can you have the skill to come up with a good design if you have no clue how to implement it or how someone else would?
This is a straw-man. Real-world designers absolutely do have a sense of implementation constraints for their target platforms, yet are usually not deep implementation domain experts. Likewise, experienced UI devs often have a sense of design, but are often not going to draft and refine a whole-cloth new design. I’ve also met a rare unicorn or two: those magic individuals who are fully capable developers and designers.
Put another way: UI design and UI development are adjacent specialties. Visually, they’d be partially overlapping regions in a Venn diagram. A UI designer or a UI dev who somehow knows nothing of their peer discipline will be hamstrung. I’ve met devs who fit this bill, not by their own design, and they’re usually radically unhappy with their work until they manage to pivot to non-UI development.
Comment · 5 years ago
From the Dec 28 update:
The XMLRPC Search endpoint remains disabled due to ongoing request volume. As of this update, there has been no reduction in inbound traffic to the endpoint from abusive IPs and we are unable to re-enable the endpoint, as it would immediately cause PyPI service to degrade again.
This is an ongoing attack on PyPi's search backends since around December 14 from the status logs. For context, this has entirely disabled 'pip search'.
Comment · 5 years ago
Washington State has a single-subject rule that affects both bills in legislature and ballot measures[1]. We've regularly had poorly crafted voter initiatives tossed out by the WA State Supreme Court on this basis.
[1] https://ballotpedia.org/Laws_governing_the_initiative_proces...
Comment · 6 years ago
AnandTech speculates on a 128-bit DRAM bus[1], but AFAIK Apple hasn't revealed rich details about the memory architecture. It'll be interesting to see what the overall memory bandwidth story looks like as hardware trickles out.
[1] https://www.anandtech.com/show/16226/apple-silicon-m1-a14-de...
Comment · 6 years ago
This article leaves more questions than it answers. Room-elephant number one: access being available after an employee has left is bad. That access remaining five months later is beyond the pale, unless the real story is that the employee created a backdoor. Barring a backdoor, there are further serious questions about the employee retaining this access, presumably without any employer-provided and controlled hardware (e.g. laptop, yubikey, or what-have-you).
Room-elephant number two: motive. The reported facts naively summarize as "oops, ex-employee blew up some stuff in prod, caused problems". <meme>But whyyyyy??</meme> There's no indication of specifics, and seeming denials of some obvious guesses: attempts at hacking (e.g. data exfiltration for profit, which are denied), ransomware, revenge, or anything else that would explain this behavior.
Further confounding everything is the bit where the new employer's response to these revelations is apparently "shrug".
Let me be clear: I later realized that this project would have been a soul-draining death march at many other places I'd worked in my career. Exhausted just a few weeks in, with management hounding the team for schedule estimates that can't possibly exist because management failed to fund maintenance for years.[2] (There were actually rational reasons for this, in this case. tl;dr the project got renewed interest and investment due to a new business case.)
To those who lament on this topic about "devs (in country X) just aren't motivated these days" or whatever, let me suggest something. If you have poor clarity of purpose, poor giving-a-fsck about humans, or a number of other culture failings then yes, you may encounter problems. Your solution is still not to tie your knowledge workers to their desks. You need to fix the root causes of your underlying productivity debt, not pave over them with an overwork-butts-in-seats mentality which just makes things worse in the long run (<--- read DeMarco).
[1]: https://www.amazon.com/Slack-Getting-Burnout-Busywork-Effici...
[2]: Pro tip: "evergreen" ecosystems, especially young and rapidly changing ones like early-mid Ruby/Rails and a lot of current npm/JS-based stuff, often have a wickedly non-linear cost curve if/when maintenance and dependency updates fall off. Some of the most expensive I've encountered of this ilk is when /test infrastructure/ incurred a lot of past churn that wasn't tracked, but suddenly (cough) needs to be updated.