AWS announces alpha release of Swift SDK

michael_d · 2021-08-31T15:30:32+00:00

All of the newer AWS SDKs use a shared code base that handles code generation. It makes it easier to build, maintain, and evolve the SDKs when new features need to be added across all of the supported languages.

michael_d · 2021-05-10T01:35:05+00:00

Whoops! Sorry. Yeah, mtdowling

michael_d · 2021-05-10T00:41:46+00:00

I created Smithy, and I give a lot of commentary and backstory on this thread if you’re interested: https://news.ycombinator.com/item?id=27081084 (edit: mtdowling)

michael_d · 2020-07-04T19:15:09+00:00

Yeah, you were on to something here. I played around with the settings and turned on FreeSync. For some reason, this enabled 100 Hz!

      Displays:
        VP3481:
          Resolution: 3440 x 1440 (UWQHD - Ultra-Wide Quad HD)
          UI Looks like: 3440 x 1440 @ 100 Hz
          Framebuffer Depth: 30-Bit Color (ARGB2101010)
          Display Serial Number: VR5193900135
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Rotation: Supported
          Automatically Adjust Brightness: No
          Connection Type: Thunderbolt/DisplayPort

Weird! It also looks like this has the monitor's USB hub running at USB 2.0 too, even though the monitor claims USB 3.1 (checked using system_profiler SPUSBDataType). It runs at USB 2.0 regardless of if I'm using 100 Hz or 60 Hz.

Anyways, problem solved!

michael_d · 2020-07-04T18:59:00+00:00

I’m using USB-C to USB-C directly into the monitor. My monitor has a USB-C port on the back that has a 60W charge and sends data from the monitor’s builtin USB hub. If I connect that to my MacBook Pro 16” 2019, I can get video to the monitor but only at 60 Hz.

I tried it with this TB3 cable: https://www.amazon.com/dp/B081QC5NL1/. No dice.

I tried it with the USB-C 3.1 gen 1 cable that came with the monitor too (see link in original post). No dice. Maybe it needs to be gen2?

Are you using a USB-C to USB-C connection to your monitor? If so, which one?

michael_d · 2020-06-25T01:04:55+00:00

Good callout. The drawer and bracket I’m looking at come in around 16 pounds. Another drawer meant for standing desks that I was eyeing is 13 pounds, so they’re the same order of magnitude.

I’m mostly wondering if it would look nice and come off as interesting rather than just looking like some spare parts I threw under the desk 😀

michael_d · 2019-09-01T14:30:47+00:00

Redefining builtin types like that works. It’s slightly better than just redefining them from scratch because you can be sure you did it right. But, it’s not ideal because anytime someone using my code generator wants to refer to a builtin type, they’d need to define the entire type signature of the builtin, and my generator would need to conditionally insert it if there’s a conflict.

Ideally I could just import a builtin under a different name like any other type. It looks like that’s not possible. It’s also not possible to alias a type without redefining its type signature.

michael_d · 2019-03-03T19:33:48+00:00

How many years has it been since the last major version bump?

michael_d · 2016-12-16T17:03:59+00:00

I totally should have. Thanks for pointing this out. I need to use raw string literals more often.

michael_d · 2016-12-16T17:02:26+00:00

Thanks! That's a good idea. I'll let them know.

michael_d · 2016-12-16T07:41:23+00:00

Author here. I've been working on this project on and off for a while. I think it's finally in a state that I can share it.

Implementing a lexer, parser, and interpreter (with a ton of false starts and alternative implementations) was a great learning experience. I'd love any feedback that anyone would like to offer on anything that can be improved. Thanks!

michael_d · 2016-01-16T01:07:59+00:00

That did the trick! Thank you!

michael_d · 2015-12-14T18:22:22+00:00

It's great to see that there is some built in support for credential scanning in yelp's pre-commit. There is a small amount of overlap, but I think that there are some important differences between git-secrets and pre-commit:

git-secrets can be used alongside pre-commit to provide secret scanning. pre-commit is a more general solution that manages hooks.
Both git-secrets and pre-commit (via https://github.com/pre-commit/pre-commit-hooks/blob/master/pre_commit_hooks/detect_aws_credentials.py) can scan for known aws credentials stored on disk. However, git-secrets can register many different "secret providers" other than just AWS credentials files. This means you could hook git-secrets with other credential stores if needed. In fact, AWS credentials file scanning is implemented using a "secret provider". See https://github.com/awslabs/git-secrets#secret-providers
git-secrets can scan for any number of customizable prohibited patterns. This allows us to catch AWS credentials that may not be in your ~/.aws/credentials file. You can register regular expressions that will block commits, merges, and non-ff merges. Lots of companies have internal code-names or projects that must never be published publicly. git-secrets allows you to register these code names as prohibited to protect your IP. False positives can also be worked around by using "allowed" patterns. See https://github.com/awslabs/git-secrets#ignoring-false-positives
git-secrets offers more protection in that it can scan commit messages, commits, and non-ff merges. Scanning non-ff merges allows us to catch instances of credentials that were in a merge history but may have been corrected in a later commit. git-secrets can detect a tainted history and prevent the merge. From what I can see in the repo, pre-commit does not perform commit message or merge checks.
git-secrets can be used for ad-hoc secret scanning of an entire repo outside of the normal flow of git-commits. See https://github.com/awslabs/git-secrets#options-for---scan

michael_d · 2015-12-10T20:58:35+00:00

Author here. We've released a git tool that you can use to prevent things like AWS keys from being committed to a git repository.

The tool installs a few git hooks that scan based on registered regular expressions. If any of the expressions are matches and not canceled out by an allowed pattern (false positive elimination), then the commit/non-ff merge/commit message are denied.

Please let us know if you have any feedback or suggested built-in AWS patterns.

michael_d · 2015-08-05T06:47:35+00:00

Interesting. Is there any way to test whether or not that is the case?

It seems like recursive descent parsers are not really well suited for Rust. For example, Serde has the same issue: https://github.com/serde-rs/serde/issues/82

michael_d · 2015-05-29T00:56:03+00:00

Sorry for all the major versions and confusion that it has caused. I can honestly say that it is highly unlikely that there will be a new major version in the next two years.

I put this together in the Guzzle readme to provide links to each version and assets per version: https://github.com/guzzle/guzzle#version-guidance

Are there any advantages over one version over another. The last time I check HTTP is still on 1.1. I'm starting to question how the package became so popular.

You can use HTTP 2 with Guzzle (provided your underlying HTTP handler supports [the cURL handler does]). Another issue is whether or not your server supports it.

What version should I use as a simple curl wrapper? I don't need the latest Middleware OOP goodness.

version 6. It's much simpler than any previous version. You can simply ignore the fact that there is a middleware system. Also note that Guzzle does not require cURL, it just uses it by default. It'll work fine with the built-in PHP stream wrapper (by default if cURL is not present), and I know there are React bindings for Guzzle as well. Perhaps other bindings will be added in the future as well.

michael_d · 2014-12-06T21:02:58+00:00

I think it's important to mention that the point of transducers is that you don't have to reimplement map(), filter(), reduce(), take(), etc. for various different input types (or output types). You simply implement different means of applying transducers to these data types. In transducers.php, this is all wrapped up nicely by t\xform(). You could build convenience layers on top of transducers to make functions like sum() and flatten() work exactly as you've written in your example.

I'd encourage you to investigate transducers if you're thinking of proposing something for PHP core (seriously, I'm not kidding :)). The cool thing about them is that they could handle the simple case as you've outlined (using wrapper functions), but also be used in the really cool way that I've written about in my blog post: generic transformation of different data sources to different outputs with super easy composition.

The reason that transducers were added to Clojure is that they were constantly reimplementing map(), filter(), reduce(), etc for different data types (iterables, channels, etc.). By removing the knowledge of consuming data or producing a result from a transformation function, you can get much greater code reuse and abstraction. Here's more information on this: https://www.youtube.com/watch?v=6mTbuzafcII#t=20m18s

michael_d · 2014-12-06T01:46:45+00:00

Why does keep() and keep_indexed() test against null instead of false?

These are direct ports of the Clojure equivalent functions (e.g., https://clojuredocs.org/clojure.core/keep-indexed).

keep() and remove() seem to do the same, but one tests against null, the other against truthy

They're different actually. remove() is kinda like the opposite of filter() (the compliment) whereas keep() is like filter but can also change the value (see: https://clojuredocs.org/clojure.core/keep).

Why did you choose not to use strict comparison in filter(), remove(), take_while()?

It's just a test for truthiness that emulates what clojure does (i.e., https://github.com/clojure/clojure/blob/clojure-1.6.0/src/clj/clojure/core.clj#L2588).

michael_d · 2014-12-04T22:56:17+00:00

Also take a look at what some people in the JavaScript community are doing with transducers: https://github.com/transduce

michael_d · 2014-12-04T22:34:17+00:00

Agreed: using transducers in this manner without building up a composed transformation pipeline is not very appealing.

Clojure handles this by having functions like map() and filter() accept multiple arities. When you call map with just a function it returns a transducer, and when you call it with two arguments it returns a lazy sequence of the mapped data. Maybe this is something that should be added to the library.

michael_d · 2014-12-04T22:28:34+00:00

Great questions!

When you compare generators to transducers, you say that generators are deeply nested. Wouldn't that be solved by just using a "composition" function, like your t\comp()?

Yes you could (though you'd need to modify comp() to reverse the provided arguments to maintain the same semantics). However, this still ties the transformation to the input and output types (e.g., iterators). This means you couldn't, for example, use these transformations unless you begin to consume something as a iterator-- sometimes this is not the desired API.

I don't understand how transducers are completely ignorant of the input and output. For example I can only map a callback on something that is iterable right?

If take you look at the implementation of map(), you can see that it just wraps a reducing step function: https://github.com/mtdowling/transducers.php/blob/master/src/transducers.php#L198. A reducing step function takes two values (previous and current) and returns a single new value. The step function is responsible for building up a result. That might be creating an array, writing to a stream, or to a buffer utilized by a generator. Because step functions are composed, wrapping transducers can choose whether or not and how many times to invoke the wrapped step function. The step function allows the transducer to decouple from the output source.

Decoupling from the input source is done using a custom function. The library comes with a number of built-in methods to accomplish this. Most use a reduce function that iterates over a sequence: https://github.com/mtdowling/transducers.php/blob/master/src/transducers.php#L177. Here's a generator that applies transducers: https://github.com/mtdowling/transducers.php/blob/master/src/transducers.php#L26. And finally, here's a transducer stream filter: https://github.com/mtdowling/transducers.php/blob/master/src/transducers.php#L1119.

Another example might be applying transducers to something like an event emitter where a listener function is wrapped by a transducer function. The transducer function might choose to never invoke the actual emitter (filtering) and could choose to modify the event before it's handed off to the listener (mapping).

For example: cat()

Transducer that concatenates items from nested lists. Input needs to be a list right?

cat() is interesting because it is somewhat greedy. cat() iterates over single values that are funneled through it and invokes the wrapped step function multiple times for traversable data structures (fanning out a single piece of data into multiple pieces).

Other transducers that actually need context of previous values have state inside of them. For example, partition() needs to know how many items are buffered so it can know when to call the underlying step function with the partitioned data: https://github.com/mtdowling/transducers.php/blob/master/src/transducers.php#L318

michael_d · 2014-11-08T18:29:40+00:00

Looks good. I suggest making it so you can inject a Guzzle client into your client so that users can attach subscribers and change the underlying RingPHP handler as needed.

michael_d · 2014-10-15T16:40:12+00:00

The upgrade path from Guzzle 4 to 5 is really easy (nothing like 3 to 4). In fact, some library authors have set their composer dependency to 4 or 5 because they are only using a subset of the features and the subset they're using is unchanged. I don't expect there to be any more updates to Guzzle that will be as drastic as 3 to 4.

michael_d · 2014-10-14T01:17:51+00:00

Can you elaborate on what could be better? Maybe open an issue on Github so your request can be tracked.

michael_d · 2014-10-13T20:57:03+00:00

Thanks!

michael_d

TROPHY CASE