Python 的 code formatter:Black

Black 是一套 Python 上的 Code Formatter,可以幫你重排程式碼以符合 coding style 與 coding standard,比起只是告訴你哪邊有錯來的更進階...

記得以前好像不是掛在官方帳號下面的,翻了一下發現在 Hacker News 上的「https://news.ycombinator.com/item?id=17151813」這則可以看到,去年在 ambv 的 repository 上,現在則是被導到 python 的組織下了 :o

目前還是掛 beta,另外有不少 practice 讓人不太舒服,像是 Hacker News 上「https://news.ycombinator.com/item?id=19939806」這邊提到的:

Against my better judgment I'll bite.
I super dislike black's formatting, and I think it's really rare to actually see it in codebases. It wraps weirdly (sometimes not at all). I'd prefer to use yapf, but last I checked it still crashes on "f-strings".

Here's a small example:

    basket.add({
        apple.stem
        for satchel in satchels
        for apple in satchel
    })
Black formats this as:
    basket.add(
        {
            apple.stem
            for satchel in satchels
            for apple in satchel
        }
    )
        
I've never seen Python code like that.
I totally believe using a formatter is good practice. Black is in a challenging position of coming into a community with a lot of existing code and customs, and I get that. But I also think that's an opportunity, rather than having to guess at what is good, there's a wealth of prior art to look at. I wish it had done this, rather than essentially codify the author's style.

看起來還有很多可以調整的,然後也可以考慮用看看... 以前是 3rd-party 還可以丟著不管,現在帶有官方色彩得看一下 :o

Amazon S3 淘汰 Path-style 存取方式的新計畫

先前在「Amazon S3 要拿掉 Path-style 存取方式」提到 Amazon S3 淘汰 Path-style 存取方式的計畫,經過幾天後有改變了。

Jeff Barr 發表了一篇「Amazon S3 Path Deprecation Plan – The Rest of the Story」,裡面提到本來的計畫是 Path-style model 只支援到 2020/09/30,被大幅修改為只有在 2020/09/30 後建立的 bucket 才會禁止使用 Path-style:

In response to feedback on the original deprecation plan that we announced last week, we are making an important change. Here’s the executive summary:

Original Plan – Support for the path-style model ends on September 30, 2020.

Revised Plan – Support for the path-style model continues for buckets created on or before September 30, 2020. Buckets created after that date must be referenced using the virtual-hosted model.

這樣大幅降低本來會預期的衝擊,但 S3 團隊希望償還的技術債又得繼續下去了... 也許再過個幾年後才會再被提出來?

Amazon S3 要拿掉 Path-style 存取方式

Hacker News 上翻的時候翻到的公告:「Announcement: Amazon S3 will no longer support path-style API requests starting September 30th, 2020」。

現有的兩種方法,一種是把 bucket name 放在 path (V1),另外一種是把 bucket name 放在 hostname (V2):

Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com/<bucketname>/key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //<bucketname>.s3.amazonaws.com/key).

這次要淘汰的是 V1 的方式,預定在 2020 年十月停止服務 (服務到九月底):

Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.

Virtual-hosted style requests are supported for all S3 endpoints in all AWS regions. S3 will stop accepting requests made using the path-style request format in all regions starting September 30th, 2020. Any requests using the path-style request format made after this time will fail.

SQL 的設計與寫作規範

看到「SQL Style Guide」這個網站,把 SQL 常見的行為都列出來,寫了一份規範... 每個團隊未必都要照這個規範走,可以透過他條列的項目思考,再改成自己團隊的規範。

附註一下,最底下有繁體中文的翻譯版本,如果懶的看英文的版本可以看這份:「SQL樣式指南 · SQL Style Guide」。

相對路徑的攻擊方式 (Relative Path Overwite,RPO)

在「Large-scale analysis of style injection by relative path overwrite」這邊看到的,記得這個方式不是新方法,不過還是有人會中...

這種攻擊是組合技,基礎是引用 css 或是 js 時使用相對路徑 (像是 static/style.css 這樣的引用法),再加上 https://www.example.com/a.php 這樣的頁面通常也可以吃 https://www.example.com/a.php/,甚至是後面再加東西... 在某些情境下組不出來,但精心策劃後就有機會在頁面上弄出奇怪的 xss 或是其他攻擊了。而論文內列出了常見的的組合:

然後拿 Alexa 的排名來看,其實還是有些站台可以打:

防禦的方式也不算太難,absolute path 是個還不錯的方式:

One option is to use only absolute URLs, taking away the relative path expansion.

base tag 也是個方式 (不過在 IE 上還是有問題):

Alternatively you can specify a base tag, though Internet Explorer did not appear to implement the tag correctly (i.e., was still vulnerable) at the time of the evaluation.

另外作者也提到了 document type 的方式 (看起來是建議用 html5 的 <!DOCTYPE html>),然後 IE 另外做些處理避免失效:

One of the best mitigations is to avoid exploitation by declaring a modern document type that causes rendering in standards compliant mode. This defeats the attack in all browsers apart from IE. For IE it is also necessary to prevent the page being loaded in a frame by using X-Frame-Options , using X-Content-Type-Options to disable ‘content type sniffing,’ and X-UA-Compatible to turn off IE’s compatibility view.

不過大型站台本來就因為業務需求,會把 asset domain 切開 (然後透過 CDN 加速),而且會設計系統讓 programmer 很容易使用這樣的架構,反而因此比較不會用到 relative path,中這個攻擊的機會就低多了...

Firefox Nightly 的 Stylo

Firefox 的 Nightly 納入 Stylo 了,一個用 Rust 開發的套件,可以將 Servo 的 CSS style system 整進 Gecko 內:「Stylo is ready for community testing on Nightly!」。

Stylo (a.k.a. Quantum CSS) will integrate Servo's CSS style system into Gecko, such that the style system code can be shared by Gecko and Servo.

Quantum CSS, aka Stylo, aims to integrate Servo’s parallelized CSS style system written in Rust into Gecko.

Mozilla 把愈來愈多的東西都改用 Rust 寫了...

把塗鴉透過深度類神經網路轉成油畫...

看到「Neural Doodle」這個專案,可以把塗鴉轉成帶有油畫筆觸的圖:

看起來是實作新的演算法:

Use a deep neural network to borrow the skills of real artists and turn your two-bit doodles into masterpieces! This project is an implementation of Semantic Style Transfer (Champandard, 2016), based on the Neural Patches algorithm (Li, 2016).

另外一組範例:

程式可以用純 CPU 跑,也可以用 GPU 跑,不管哪種都很吃記憶體 XDDD

18F 丟出 CSS 的代碼風格指南

好幾個禮拜前的東西,這幾天才上 Hacker News:「Introducing the CSS coding style guide」。

18F 是美國政府的官方單位,取名自辦公室所在的地址:(取自 Wikipedia 的「18F」說明)

Its name refers to its office location in northwest Washington, D.C., on 18th and F Streets.

不只是定義了 CSS Coding Style Guide,還給了 SCSS Lint 工具使用:

The styleguide provides a method of linting Sass (SCSS) code to ensure it conforms to the rules in the styleguide.

在 Gmail 上做 CSS 效果的問題

TechCrunch 上看到的「Gmail, We Need To Talk」這篇裡提到 Gmail 的問題,尤其是 CSS 這塊:

Each Gmail client renders email differently. You may not be aware of this, but each Gmail client has its own set of frustrating quirks. Having to deal with each version of Gmail makes creating email a nail-biting chore:

  • Gmail.com Webmail. Supports <style> but does not support ids and classes.
  • Gmail Webmail for Business. Does not support <style>.
  • Gmail App for iOS. Randomly increases font sizes by 50 percent (no <style>).
  • Gmail App for Android. Randomly ignores container widths (no <style>).
  • Gmail App for Android (for non Gmail.com addresses). Does not support background images in addition to ignoring container widths (no <style>).
  • Inbox by Gmail for Android. Randomly ignores container widths but does so differently than Gmail App for Android (no <style>).
  • Inbox by Gmail for iOS. Does not support <style> but seems to not suffer from as many quirks as other Gmail mobile apps.

這也就可以理解為什麼有時候手機上看起來怪怪的了 XD