mistahenry

As far as I can tell, the previous commenter was in agreement with the sentence he quoted, going so far as to say that the “on a dime” stipulation isn’t even necessary to consider the idea that we “must always be prepared for it to do something unexpected” an absurd reality

In my driver’s education course back in the early 2000s, they explicitly told us that Cruise Control can dangerously malfunction in rain and should only be used on dry roads.

That’s an unfair characterization if you’re talking about the crash in Arizona. Perhaps: “Did you hear about the Uber crash where the AI couldn’t track a pedestrian jaywalking at night across the middle of a nearly pitch black two lane highway and then killed her?” would have been more apt. https://youtu.be/ufNNuafuU7M

That being said, I’m a huge skeptic of the current state of self driving cars. I would have assumed these systems use LIDAR as well as vision and could have at least slammed on the brakes.

Most, if not all tooling, comes with a learning curve. But once you pay it, that initial ramp up time is not required on the next project.

I could start a new project with Spring Boot and Ember.js, provision a Debian box with Postgres and nginx, and deploy all of it within an hour because I know these tools. But I too paid the learning price my first go round.

Assimil is the best program I've found so far for learning a foreign language. The way you learn the language feels very natural to me. I used their book but they've recently released an app which may be good.

I also recommend Pimsleur as a supplement to work on your accent and listening skills. Don't let the limited vocabulary misguide you...Pimsleur teaches and emphasizes a lot of very useful language patterns/structures. Great tool in the language learning toolbox

> It's astonishing how many developers rely on logging/print statements for debugging. The learning curve of using a tool like PDB or GDB is just too steep for most people.

On the other hand, since I can’t hook up a debugger to production, it’s also very useful to be able to understand my applications log output (especially tracing/debug statements) to triage the situation as quickly as possible.

Also any time I’m debugging USB or Bluetooth LE protocols, I’m relying on some kind of Wiretrace-like packet logger.

Debuggers have their place but they aren’t the end-all be-all of debugging.

I can think of a bunch off the top of my head that mostly stem from a serious reduction in complexity:

- having one data store instead of two

- no data store synchronization and related consistency headaches

- the ability to easily join/restrict based on business logic (especially access control)

- easier deployments

- easier qa/local setups

- fewer failure scenarios

- although non-standard, you're dealing with sql and can explain/analyze your queries with tools one already knows if one understands postgres

- the ability to extend my existing (Spring Boot) integration tests to test new searching logic without having to worry about a separate test db.

I've been building a travel blogging platform as a side project that has about ~250 users. Through a couple of choice materialized views to create search documents from a number of different tables, Postgres FTS, and some GIN indices, I was able to make a lighting fast search with intelligent suggestions(ie using user specific restrictions such as follower/following, places a user has posted, etc).

Is my search perfect? No. I could do a better job normalizing diacritics, stemming could be improved, etc. But it was dead simple to implement well enough in a very short amount of time. I'm very happy with my current solution. There's a time and place for a dedicated search solution but it's certainly not in fledgling systems without massive load.

IMO there's a huge difference between invasive and non-invasive attacks. I would expect something that bills itself as "The safe place for your coins" to require a bit more effort, know-how, and tools to read out my keys than "a couple hundred dollars of equipment" and a python program.

> if anyone has physical access it's game over

It's actually not when you use a series of common defenses that wipe the chip when tampering is detected. Of course it's still possible to determine the private keys via perfectly executed microprobing...but there's a huge difference here. Invasive attacks require significant time in very expensive laboratories per attack, which very well may fail.

Let's say managed to steal my wallet which leverages a secure element with tampering protection. If you're unaware that voltage/clock glitching will wipe the device, you may try and then you've lost. But let's say you're aware so you want to go the microprobing route. Do you have the necessary lasers and acids to get directly to the circuitry you want to read out without accidentally compromising the integrity of the top-layer sensor meshes? Do you possess a focused ion beam station (only costs ~500k USD)? By using this mesh I've made the extraction significantly more tedious and requiring far higher levels of precision for you. You've got my smart card, but I wouldn't call it "Game Over" by any means. Maybe in this amount of time I figured out that my wallet is missing.

This attack here on the Tresor, though, requires physical access but can be automated. Here, physical access really is game over. I would rate this issue as "Trezor shows themselves to be an inferior solution, will not use to store my keys"

Read here if you want to see more on techniques for readout and known countermeasures. https://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf

To me, this is full admission of a complete lack of security competency. Building a hardware wallet without using a smart card or some other secure element that at least has mitigation’s against voltage/clock glitching, detects light, reduces the ability to measure power consumption, etc is negligent.

Either they don’t know how to design secure solutions or they wanted to use cheaper chips since tamper resistant chips cost more. Neither is a good look

It’s my understanding that banks in the EU must make their APIs public after PSD2. So...regulation is about the only thing they will get the incumbent to share their data

On the other hand, grep can be far faster for searching alone than awk. I almost always use an initial grep for the string that will most reduce the input to the rest of the pipeline. Later, it feels idiomatic to mix in awk with matches like you suggested

In my experience, learning a second language has clogged my brain up a bit. Maybe it’s healthier and more engaged, but it’s sometimes hard to say if it’s truly been beneficial from a cognitive perspective.

I’ve certainly been humbled and become more confident in pushing through mistakes made in public. It’s also a really cool skill. But it often feels like my memory for words is like a unordered linked list. Sometimes I get the wrong language and must iterate over the list to find the correct language version.

In my opinion, Assimil for learning the grammar and Pimsleur for speaking and listening comprehension. That’s how I learned German by myself enough in a year to get a job in Germany

More important than the method, though, is that you never miss a day of practice

Too true. I self taught German to a low C2 in 2 years or so as a native English speaker. I got to a very high level of grammar in a matter of months, but since vocabulary took far longer to acquire, I was left having most conversations sound like “I would have ___ if only I had known ____ was ____ing ____.

I moved to Germany from the US, and I’d say that traveling is still very different from being at home in 2019.

With regard to connection reducing the adventure when traveling, how connected you are at any time can be a choice. Sure, back in the day you had no life line. But to me it’s a bit like free solo climbing (no ropes) vs lead climbing. Free solo is max adventure but the consequences are higher. It’s your choice in what you want the challenge to be. But if you really only care about challenging yourself on the climb itself and you don’t fall in either, was there really much of a difference? Having the safety net let’s you push harder and avoid being too conservative

Let’s say I have a newsletter generation service for a website. Users can opt of emails. I use AWE SES for sending emails. I would like to test that emails are sent unless you’ve opted out.

First, I don’t know how to accomplish this without mocking / replacing the email dependency before testing, even in an integration style test. Emails cost and how would I even verify if I did send the email. Second, I really am failing to see how this is poor design and am genuinely curious.

I can think of so many scenarios where some “orchestrating” service uses multiple single unit services to pull off some task. To me, mocking is incredibly useful for ensuring that you test a lot of failure cases in these scenarios by mocking to force an exception.

A lot can be accomplished via integration tests rather than mocking (actually using a database for example). But to somehow suggest mocking is across the board bad seems like an illogical position

They would also hesitate to build an app that only works in iOS 13+ when iOS 13 is the current iOS

Can’t you just handle these sorts of consistency issues with uniqueness, foreign key, and check constraints?

It was two weeks ago when I started suddenly having delivery problems (ie consistently delivered to the spam folder) for emails sent from SES from AWS.

It’s very obvious to me now when reading these replies that Google changed their spam filtering and it’s affecting many more than just me

This same thing started a few weeks ago for me as well. I have a cron job that parses my log file and sends me usage statistics every morning. I had been receiving this email for 100+ days when suddenly it stopped. I investigated thinking it was a problem in my script only to find that all worked well and all emails were in my spam.

I use SES from AWS and now my new user sign ups emails for email verification also end up in spam. It’s very frustrating because they changed some rule and now my low volume email sending is considered spam

Lol this one was painful. And they also moved where the peripheral identifier is located in the object hierarchy to a superclass CBPeer which was wrapped in available MacOS 13+. So all my existing code that referenced the identifier on the CBPeripheral where it was prior to MacOS 13 needed warning suppression since identifier has been available through the object hierarchy on peripheral since forever

I support a MacOS app that connects to hardware devices via Bluetooth low energy and/or USB back to 10.7. First off, Apple makes it damn near impossible to test old versions, but we have every OS in a parallels VM and have copies. Every single release introduces breaking changes. We also bundle a version of our app on the hardware device and this is a big deal for us when an old version stops running on a new machine/OS. The way they’ve changed ATS over the years has broken across major versions.

They’ve changed Bluetooth chipsets a number of times over the years and each one has its own behaviors which makes writing one single BLE communication library that works for all versions very difficult. For instance, in the latest chipset, if you try to increase throughput by using a mixture of ble characteristic writes with and without response, you can very easily end up in a deadlock situation. It appears the hardware buffer just drops ble packets including those with response if full (which appears to hold 5 packets in the latest 2019 MacBook Pro). Dropping without response packets is fine since they’re expected to be unreliable (and you can build a reliable protocol on top) but they drop the write with response packet which the firmware blocks forever on (you can see this pretty clearly when using a ble packet logger). There’s no timeout and all subsequent packets are queued and never sent. Reliable writes should never be dropped!

Every new MacOS/iOS release is a worrying event. Testing the betas which are super unstable increases the tension because you never know if they’ll fix certain breaking changes. Up until the latest beta, our app did not work on iOS or MacOS until they rolled back some ATS hardening because they didn’t like the certificate pinning style we did of manually evaluating trust (which worked countless versions back).

If my app completely stops working during a beta, are you suggesting that I should just wait until the actual release to find out that my app is in fact really broken should that be the case? And only then develop a new release for my app and release it as soon as possible, all the while having a deficient product for however long this may take?

I've always viewed a beta as a way to test that my app has not regressed. If it has, I open issues with Apple (or whomever). If these issues are either cited as not-to-be-fixed or I hear nothing back, I will create a release of my apps that works around whatever issues are there. IMO determining breaking changes in beta versions allows one to develop fixes as well as create and plan the rollout of the new software before the beta goes lives (and therefore avoid any regression/downtime).

I was trying to run versions of our app built between 2011 - 2016. None of them would open in the MacOS 10.15 beta. Before this September 3rd announcement, any attempt to notarize the app would be rejected for not having hardened runtime. I can still use `xcrun altool --notarization-info` to view old notarization reports and reasons for rejections. One such app from 2014, which I attempted to notarize on 2019-08-23 was rejected for reasons such as:

    {
      "severity": "error",
      "code": null,
      "path": "my/app/path",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "my/app/path",
      "message": "The executable does not have the hardened runtime enabled.",
      "docUrl": null,
      "architecture": "x86_64"
    }

I saw this announcement on September 3rd and upgraded the beta. My apps would not open still. So I went and notarized my old apps and this time all of them succeeded in notarization. As soon as the app was notarized, I could open the app in the beta.

In my opinion, a number of people in these threads are missing the point when they suggest: "You can easily run these programs if you just do these quick tricks like using the command line or removing an xattr from the file or a special click workflow" There are companies out there making software for normal people (ie non technical) who will think your app is broken if double clicking doesn't work. These people will call your support lines and this will cost your company money

In early versions of the MacOS beta, the right-click open did not work, nor did starting the app from the command line. I never tried checking for the quarantine attribute and subsequently altering so I cannot comment there.

You also couldn't notarize old apps that weren't built with secure timestamp, hardened runtime, etc (a lot of versions of some software I'm supporting back to 10.7 preexisted some of the required criteria) until the beta release that coincided with this announcement in early September.

I think Apple relaxed their stance here because they did not want the average person to think that Catalina was breaking their apps and have subsequently deferred their "hardening" to January 2020.

In my development as a software engineer, there was a noticeable "level up" after 3-4 years where I had accumulated enough knowledge across the various abstraction levels to the point where new concepts integrated cleanly into my mental model of software systems.

During the first few years of exposure to computer science, I definitely lacked the necessary context to understand certain concepts when I encountered them for the first time. For example, I had a theory of computation course that was all about regular expressions, regular languages, context free grammars, etc. At the same time as I took this course, I was also building my first iPhone app, and I often thought "none of this seems applicable". And then two years later I wrote a compiler to implement a subset of Java and I massively reassessed my opinion on the value of understanding the theory of computation and programming languages.

Command line tools are very terse, heavily optimized (ie fast), interactive, and easily chainable. I would never want to write a python program for quick analysis of a log file when I can grep/sed/awk/sort/uniq my way to a solution.

The other day my boss asked me to find out if there was any second where we processed more than 100 transactions a second on our server in the last 90 days. I needed to go through 100s of GB of data which mawk managed in no time and in a relatively simple one liner. I imagine my idiomatic python script would still be running

Often times, analysis is an evolving thing. As you uncover one answer, new questions arise. It’s far easier imo to tweak my command line pipelines than to modify program flow.

At the end of the day, general purpose programming languages are jacks of all trades and masters of none. They’re inherently held back by their flexibility when compared to DSLs. Text processing is so easy in awk b/c it’s a text processing domain specific language. If you really think that we should use on language for everything, you’re ignoring the value that specialization can provide you, whether in speed, power, or ease of use

It’s exactly what I find so great about Ember (beyond just preferring a true templating language for front ends)

React bringing the “same way of thinking” in the front end industry may be true now, but it definitely was not the case for many years. I saw three or four react projects and they were architected very differently, with different routing, different state patterns, different approaches to updating backend state, different build systems, etc.

How often are you spinning up new servers? In one to two hours, I can configure a production ready Debian server from base install with firewall rules, correct network interfaces, cron jobs, all dependencies and tooling, monitoring, Postgres, and my application server (either C epoll passed or Spring Boot) sitting behind an nginx proxy. I would consider myself neither a Sysadmin nor particularly fast at configuring Linux.

One to two hours per project multiplied by potentially one or two QA/UAT environments, and this is a tiny blip in the total time spent developing a solution. I think it would take me a few years before I paid back the debt of learning docker/kubernetes for it to actually start saving me time as a freelancer (or if multitenancy suddenly becomes out of the question).

From my experience, there’s always one developer in every enterprise dev shop who understands transaction boundaries, isolation levels, and concurrency/reliability scenarios that do happen....and 10 other devs constantly instilling fear in him/her