Python 命令行之旅:深入 click 之子命令篇

作者:HelloGitHub-Prodesire

HelloGitHub 的《講解開源項目》系列,項目地址:https://github.com/HelloGitHub-Team/Article

一、前言

在上兩篇文章中,我們介紹了 click 中的”參數“和“選項”,本文將繼續深入了解 click,着重講解它的“命令”和”組“。

本系列文章默認使用 Python 3 作為解釋器進行講解。
若你仍在使用 Python 2,請注意兩者之間語法和庫的使用差異哦~

二、命令和組

Click 中非常重要的特性就是任意嵌套命令行工具的概念,通過 和 (實際上是 )來實現。

所謂命令組就是若干個命令(或叫子命令)的集合,也成為多命令。

2.1 回調調用

對於一個普通的命令來說,回調發生在命令被執行的時候。如果這個程序的實現中只有命令,那麼回調總是會被觸發,就像我們在上一篇文章中舉出的所有示例一樣。不過像 --help 這類選項則會阻止進入回調。

對於組和多個子命令來說,情況略有不同。回調通常發生在子命令被執行的時候:

@click.group()
@click.option('--debug/--no-debug', default=False)
def cli(debug):
    click.echo('Debug mode is %s' % ('on' if debug else 'off'))

@cli.command()  # @cli, not @click!
def sync():
    click.echo('Syncing')

執行效果如下:

Usage: tool.py [OPTIONS] COMMAND [ARGS]...

Options:
  --debug / --no-debug
  --help                Show this message and exit.

Commands:
  sync

$ tool.py --debug sync
Debug mode is on
Syncing

在上面的示例中,我們將函數 cli 定義為一個組,把函數 sync 定義為這個組內的子命令。當我們調用 tool.py --debug sync 命令時,會依次觸發 clisync 的處理邏輯(也就是命令的回調)。

2.2 嵌套處理和上下文

從上面的例子可以看到,命令組 cli 接收的參數和子命令 sync 彼此獨立。但是有時我們希望在子命令中能獲取到命令組的參數,這就可以用 來實現。

每當命令被調用時,click 會創建新的上下文,並鏈接到父上下文。通常,我們是看不到上下文信息的。但我們可以通過 裝飾器來顯式讓 click 傳遞上下文,此變量會作為第一個參數進行傳遞。

@click.group()
@click.option('--debug/--no-debug', default=False)
@click.pass_context
def cli(ctx, debug):
    # 確保 ctx.obj 存在並且是個 dict。 (以防 `cli()` 指定 obj 為其他類型
    ctx.ensure_object(dict)

    ctx.obj['DEBUG'] = debug

@cli.command()
@click.pass_context
def sync(ctx):
    click.echo('Debug is %s' % (ctx.obj['DEBUG'] and 'on' or 'off'))

if __name__ == '__main__':
    cli(obj={})

在上面的示例中:

  • 通過為命令組 cli 和子命令 sync 指定裝飾器 click.pass_context,兩個函數的第一個參數都是 ctx 上下文
  • 在命令組 cli 中,給上下文的 obj 變量(字典)賦值
  • 在子命令 sync 中通過 ctx.obj['DEBUG'] 獲得上一步的參數
  • 通過這種方式完成了從命令組到子命令的參數傳遞

2.3 不使用命令來調用命令組

默認情況下,調用子命令的時候才會調用命令組。而有時你可能想直接調用命令組,通過指定 click.groupinvoke_without_command=True 來實現:

@click.group(invoke_without_command=True)
@click.pass_context
def cli(ctx):
    if ctx.invoked_subcommand is None:
        click.echo('I was invoked without subcommand')
    else:
        click.echo('I am about to invoke %s' % ctx.invoked_subcommand)

@cli.command()
def sync():
    click.echo('The subcommand')

調用命令有:

$ tool
I was invoked without subcommand
$ tool sync
I am about to invoke sync
The subcommand

在上面的示例中,通過 ctx.invoked_subcommand 來判斷是否由子命令觸發,針對兩種情況打印日誌。

2.4 自定義命令組/多命令

除了使用 來定義命令組外,你還可以自定義命令組(也就是多命令),這樣你就可以延遲加載子命令,這會很有用。

自定義多命令需要實現 list_commandsget_command 方法:

import click
import os

plugin_folder = os.path.join(os.path.dirname(__file__), 'commands')

class MyCLI(click.MultiCommand):

    def list_commands(self, ctx):
        rv = []  # 命令名稱列表
        for filename in os.listdir(plugin_folder):
            if filename.endswith('.py'):
                rv.append(filename[:-3])
        rv.sort()
        return rv

    def get_command(self, ctx, name):
        ns = {}
        fn = os.path.join(plugin_folder, name + '.py')  # 命令對應的 Python 文件
        with open(fn) as f:
            code = compile(f.read(), fn, 'exec')
            eval(code, ns, ns)
        return ns['cli']

cli = MyCLI(help='This tool\'s subcommands are loaded from a '
            'plugin folder dynamically.')

# 等價方式是通過 click.command 裝飾器,指定 cls=MyCLI
# @click.command(cls=MyCLI)
# def cli():
#     pass

if __name__ == '__main__':
    cli()

2.5 合併命令組/多命令

當有多個命令組,每個命令組中有一些命令,你想把所有的命令合併在一個集合中時,click.CommandCollection 就派上了用場:


@click.group()
def cli1():
    pass

@cli1.command()
def cmd1():
    """Command on cli1"""

@click.group()
def cli2():
    pass

@cli2.command()
def cmd2():
    """Command on cli2"""

cli = click.CommandCollection(sources=[cli1, cli2])

if __name__ == '__main__':
    cli()

調用命令有:

$ cli --help
Usage: cli [OPTIONS] COMMAND [ARGS]...

Options:
  --help  Show this message and exit.

Commands:
  cmd1  Command on cli1
  cmd2  Command on cli2

從上面的示例可以看出,cmd1cmd2 分別屬於 cli1cli2,通過 click.CommandCollection 可以將這些子命令合併在一起,將其能力提供個同一個命令程序。

Tips:如果多個命令組中定義了同樣的子命令,那麼取第一個命令組中的子命令。

2.6 鏈式命令組/多命令

有時單級子命令可能滿足不了你的需求,你甚至希望能有多級子命令。典型地,setuptools 包中就支持多級/鏈式子命令: setup.py sdist bdist_wheel upload。在 click 3.0 之後,實現鏈式命令組變得非常簡單,只需在 click.group 中指定 chain=True

@click.group(chain=True)
def cli():
    pass


@cli.command('sdist')
def sdist():
    click.echo('sdist called')


@cli.command('bdist_wheel')
def bdist_wheel():
    click.echo('bdist_wheel called')

調用命令則有:

$ setup.py sdist bdist_wheel
sdist called
bdist_wheel called

2.7 命令組/多命令管道

鏈式命令組中一個常見的場景就是實現管道,這樣在上一個命令處理好后,可將結果傳給下一個命令處理。

實現命令組管道的要點是讓每個命令返回一個處理函數,然後編寫一個總的管道調度函數(並由 MultiCommand.resultcallback() 裝飾):

@click.group(chain=True, invoke_without_command=True)
@click.option('-i', '--input', type=click.File('r'))
def cli(input):
    pass

@cli.resultcallback()
def process_pipeline(processors, input):
    iterator = (x.rstrip('\r\n') for x in input)
    for processor in processors:
        iterator = processor(iterator)
    for item in iterator:
        click.echo(item)

@cli.command('uppercase')
def make_uppercase():
    def processor(iterator):
        for line in iterator:
            yield line.upper()
    return processor

@cli.command('lowercase')
def make_lowercase():
    def processor(iterator):
        for line in iterator:
            yield line.lower()
    return processor

@cli.command('strip')
def make_strip():
    def processor(iterator):
        for line in iterator:
            yield line.strip()
    return processor

在上面的示例中:

  • cli 定義為了鏈式命令組,並且指定 invoke_without_command=True,也就意味着可以不傳子命令來觸發命令組
  • 定義了三個命令處理函數,分別對應 uppercaselowercasestrip 命令
  • 在管道調度函數 process_pipeline 中,將輸入 input 變成生成器,然後調用處理函數(實際輸入幾個命令,就有幾個處理函數)進行處理

2.8 覆蓋默認值

默認情況下,參數的默認值是從通過裝飾器參數 default 定義。我們還可以通過 Context.default_map 上下文字典來覆蓋默認值:

@click.group()
def cli():
    pass

@cli.command()
@click.option('--port', default=8000)
def runserver(port):
    click.echo('Serving on http://127.0.0.1:%d/' % port)

if __name__ == '__main__':
    cli(default_map={
        'runserver': {
            'port': 5000
        }
    })

在上面的示例中,通過在 cli 中指定 default_map 變可覆蓋命令(一級鍵)的選項(二級鍵)默認值(二級鍵的值)。

我們還可以在 click.group 中指定 context_settings 來達到同樣的目的:


CONTEXT_SETTINGS = dict(
    default_map={'runserver': {'port': 5000}}
)

@click.group(context_settings=CONTEXT_SETTINGS)
def cli():
    pass

@cli.command()
@click.option('--port', default=8000)
def runserver(port):
    click.echo('Serving on http://127.0.0.1:%d/' % port)

if __name__ == '__main__':
    cli()

調用命令則有:

$ cli runserver
Serving on http://127.0.0.1:5000/

三、總結

本文首先介紹了命令的回調調用、上下文,再進一步介紹命令組的自定義、合併、鏈接、管道等功能,了解到了 click 的強大。而命令組中更加高階的能力()則可看官方文檔進一步了解。

我們通過介紹 click 的參數、選項和命令已經能夠完全實現命令行程序的所有功能。而 click 還為我們提供了許多錦上添花的功能,比如實用工具、參數自動補全等,我們將在下節詳細介紹。

『講解開源項目系列』——讓對開源項目感興趣的人不再畏懼、讓開源項目的發起者不再孤單。跟着我們的文章,你會發現編程的樂趣、使用和發現參与開源項目如此簡單。歡迎留言聯繫我們、加入我們,讓更多人愛上開源、貢獻開源~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

天啦!竟然從來沒有人講過 SpringBoot 支持配置如此平滑的遷移

SpringBoot 是原生支持配置遷移的,但是官方文檔沒有看到這方面描述,在源碼中才看到此模塊,spring-boot-properties-migrator,幸虧我沒有跳過。看到這篇文章的各位,可算是撿到寶了,相信你繼續往下看下去,定會忍不住點贊、收藏、關注。

效果

先放個效果吸引你 🙂

從 SpringBoot 2.0.0 版本開始,配置服務上下文,不支持 server.context-path,而需要server.servlet.context-path配置。但是只要加上以下一個官方依賴,就可以支持使用 server.context-path

    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-properties-migrator</artifactId>
    </dependency>

server.context-path 所對應的屬性 ServerProperties#contextPath 在 Java 代碼中已不存在,server.servlet.context-path 所對應的的屬性在內部類 Servlet 中才有,為何加了此依賴就能實現如此神奇的效果呢。

原理

SpringBoot 對外部化配置原生支持遷移功能,所謂遷移,具體是指對應配置的屬性名變動,仍可以使用原來的屬性名配置。
spring-configuration-metadata.json 的信息可以輔助 IDE 進行配置的提示,也可以用來完成配置的遷移。非常的簡單。

相關文章:

通過閱讀代碼,獲得以下信息:

  1. 監聽 ApplicationPreparedEvent 事件(即:環境已準備事件),執行以下操作並收集信息
  2. classpath*:/META-INF/spring-configuration-metadata.json 中載入所有配置
  3. 從上下文的 environment 中過濾出提示的配置(滿足條件:1. deprecation 不為 null,且提示 level 為 error)
  4. 判斷是否兼容(兼容條件見下一節),提取出兼容的屬性
  5. 將 value 對應到 replacement 的 key,並將其屬性源命名為:migrate-原名
  6. 將配置遷移的新屬性源添加到 environment 中,且添加到原屬性源之前(優先級高)。
  7. 監聽事件:ApplicationReadyEvent(應用上下文已準備) 或 ApplicationFailedEvent(應用啟動失敗),打印以上步驟收集的遺留配置信息。以 warn 級別打印兼容的配置,以 error 級別打印不兼容的配置

配置兼容條件

根據元數據中定義的 type 判斷

  1. 如果舊類型、新類型其中之一為 null(元數據中未指定),則不兼容
  2. 如果兩個類型一樣,兼容
  3. 如果新類型是 Duration,而舊類型是 Long 或 Integer,則兼容
  4. 其他情況視為不兼容
  5. environment 中取配置信息,理論上支持 SpringBoot 所有的配置方式

效果

兼容效果:
棄用屬性(如果還存在)與替換后的屬性都會使用配置文件中的棄用的屬性名所對應的的值。

總結

使用配置遷移功能,需要以下步驟:

  1. 引入依賴:spring-boot-properties-migrator(支持配置遷移)、spring-boot-configuration-processor(生成元數據文件,如果已經有完整的,不需要此依賴)
  2. 元數據文件spring-configuration-metadata.json 中棄用屬性名對應的 properties 中必須有 deprecation(在additional-spring-configuration-metadata.json 中添加,相關文章: )
  3. deprecation 中需指定 levelerror
  4. deprecation 中需指定 replacement
  5. replacement 對應的屬性配置在元數據文件中存在,與棄用屬性兼容

經典示例之配置上下文

再說回一開始展示的配置上下文示例。

# 配置 servlet 服務上下文
server:
  context-path: test

從 SpringBoot 2.0.0 版本開始,以上配置不支持,點到配置元數據文件中(spring-configuration-metadata.json),發現如下信息:

{
  "properties": [
    {
      "name": "server.context-path",
      "type": "java.lang.String",
      "description": "Context path of the application.",
      "deprecated": true,
      "deprecation": {
        "level": "error",
        "replacement": "server.servlet.context-path"
      }
    },
    {
      "name": "server.servlet.context-path",
      "type": "java.lang.String",
      "description": "Context path of the application.",
      "sourceType": "org.springframework.boot.autoconfigure.web.ServerProperties$Servlet"
    }

替換屬性名為:server.servlet.context-path,此屬性在org.springframework.boot.autoconfigure.web.ServerProperties 中,且在類中可以發現,server.context-path 所對應的屬性 ServerProperties#contextPath 在代碼中已不存在,而是在內部類 Servlet 中有,也就是對應 server.servlet.context-path 的屬性才有。

但是其滿足配置兼容的條件,為什麼實際上使用卻好像不兼容呢?
其實是因為沒有引入依賴,當引入依賴,就會發現此方式配置可以起作用。

示例之兩種屬性都存在

代碼示例見

1、引入依賴

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-properties-migrator</artifactId>
</dependency>

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-configuration-processor</artifactId>
  <optional>true</optional>
</dependency>

2、Java 配置
此處故意保留棄用屬性

@Data
@Configuration
@ConfigurationProperties(prefix = "my")
public class MyProperties {
  /** the project name */
  private String name;

  private App app;

  @Data
  public static class App {
    private String name;
  }
}

3、元數據配置,spring-configuration-metadata.json 由程序生成,自定義配置放在 additional-spring-configuration-metadata.json

{
  "properties": [
    {
      "name": "my.name",
      "type": "java.lang.String",
      "description": "the project name.",
      "deprecation": {
        "reason": "test the properties-migrator feature.",
        "replacement": "my.app.name",
        "level": "error"
      }
    },
    {
      "name": "my.app.name",
      "type": "java.lang.String",
      "sourceType": "com.lw.properties.migrator.config.MyProperties$App",
      "description": "the project name."
    }
  ]
}

4、在 properties 或 yml 文件中配置

my:
  name: lw
  app:
    name: app

5、打印配置信息

@Slf4j
@SpringBootApplication
public class PropertiesMigratorApplication {

  public static void main(String[] args) {
    ConfigurableApplicationContext context =
        SpringApplication.run(PropertiesMigratorApplication.class, args);
    MyProperties myProperties = context.getBean(MyProperties.class);
    log.info("myProperties.name:{}", myProperties.getName());
    log.info(
        "myProperties$app.name:{}",
        Optional.ofNullable(myProperties.getApp()).orElse(new App()).getName());
  }
}

6、打印信息如下:

2019-11-23 21:42:09.580 WARN 109408 — [ main] o.s.b.c.p.m.PropertiesMigrationListener :
The use of configuration keys that have been renamed was found in the environment:

Property source ‘applicationConfig: [classpath:/application.yml]’:
Key: my.name
Line: 4
Replacement: my.app.name
Key: server.context-path
Line: 2
Replacement: server.servlet.context-path

Each configuration key has been temporarily mapped to its replacement for your convenience. To silence this warning, please update your configuration to use the new keys.
……… myProperties.name:lw
……… myProperties\(app.name:lw ……… serverProperties\)servlet.contextPath:/app

7、效果解析
在 yml 中棄用屬性名優先級更高,棄用屬性與新屬性都使用此棄用屬性名對應的值。

參考資料

SpringBoot 2.2.1.RELEASE 源碼
公眾號:逸飛兮(專註於 Java 領域知識的深入學習,從源碼到原理,系統有序的學習)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

嚇人!在浴池洗浴竟會感染梅毒?很多人都不知情…

  本文專家:田靖博士,南部戰區疾病預防控制中心,主治醫師

  我們都知道艾滋病很可怕,得了基本上就需要終生抗爭。

  最近,僅次於艾滋病的第二大性接觸疾病——梅毒,突然成了微博上最熱門的話題。

  某知名企業創始人稱自己“在浴池洗浴感染梅毒,打了 6 天針后治癒”。


微博截圖

  先是洗浴感染梅毒驚呆眾網友,只要在公共中心泡過澡、游過泳的都表示瑟瑟發抖。

  還有對 6 天治癒梅毒表示疑問,畢竟我們所知的梅毒是比較可怕的。

  那泡澡到底會不會感染梅毒?梅毒究竟該如何治癒?我們就網友關心的這些問題科普一下。

  洗浴、游泳真會感染梅毒嗎?

  梅毒螺旋體(Treponema pallidum,TP)又稱為蒼白螺旋體,是造成感染梅毒的“罪魁禍首”。

  目前全球每年約有 1200 萬新發梅毒病例,我國梅毒發病率呈上升趨勢。

  梅毒的感染途徑有——

  1、血液傳播和性接觸傳播

  梅毒螺旋體僅可以感染人類,血液傳播和性接觸傳播是主要途徑。95% 以上的感染者通過危險的無保護的性行為感染,而男同性戀人群中的梅毒感染率近年來急劇上升。

  2、母嬰傳播。梅毒可以通過垂直傳播途徑,由感染梅毒的母親傳染給新生兒。

  梅毒螺旋體病毒感染人類需要具備一定的病毒載量,在某些特殊條件下才能發生,如通過性接觸直接接觸梅毒感染者的創面或者血液傳播,同時也取決於被感染者的身體狀況等。

  因此,常規使用公共設施和出入公共場所,如游泳池游泳、接觸馬桶墊、共用餐具、衣物接觸等情況都不會感染梅毒。

  並且游泳池中的水通常含有漂白粉等消毒劑,不適合淋球菌、梅毒螺旋體等性病病原體存活。所以,去正規的游泳館不存在感染梅毒的可能性。

  梅毒有什麼危害?

  按照《梅毒診斷標準》(WS273-2018),根據梅毒感染的不同階段以及出現癥狀的差異可以將梅毒分為I期、II 期、III 期、胎傳和隱形梅毒。

  I 期~III 期梅毒對於患者的損害是不同的,能造成——

  1. 硬下疳、腹股溝或患部近位淋巴結腫大;
  2. 多個部位的瀰漫性皮損,最終造成頭面部以及四肢產生結節性梅毒疹;
  3. 關節出現結節;
  4. 皮膚、口腔、舌咽出現樹膠腫;
  5. 產生骨梅毒、眼梅毒、心血管梅毒、神經梅毒和其他內臟梅毒等。

  胎傳:所有未經有效治療的梅毒母親所生的嬰兒可能感染胎傳梅毒,根據發病時間分為早期胎傳梅毒、晚期胎傳梅毒和隱性胎傳梅毒。

  隱形梅毒:無臨床癥狀與體征的隱性梅毒患者,仍然具有傳染性,部分病人可以發生晚期損害。

  晚期梅毒可導致不可逆的心血管損傷和中樞系統損害,嚴重者可導致死亡。

  中樞神經系統的梅毒感染可以發生在疾病的任何時期,病程越長、精神癥狀越嚴重。

  此外,梅毒與艾滋病常常是一對“好兄弟”。在感染艾滋病的患者中,大約有 42.8% 的患者都曾感染梅毒。

  梅毒感染會造成皮膚破損,增加體液中 CD4+ 細胞的數量,為 HIV 的感染提供更多的靶細胞,促進 HIV 的傳播,因此從這個意義上來說,感染梅毒是艾滋病的“幫凶”。

  梅毒真能 6 天治癒嗎?

  不一定!

  因為涉及個人體質、治療抗生素的使用方案及青霉素是否過敏等問題,治療周期和結果都會因人而已,最重要是嚴格遵循醫囑和臨床檢查結果。

  因此,治癒的時間根據選擇藥物和患者的病情來確定,不能簡單用時間判斷!

  感染梅毒該如何治療?

  青霉素是治療梅毒的首選藥物之一,對病原菌的細胞壁生成進行抑制 , 從而降低抗原反應素,可短期改善認知功能。青霉素過敏者可採用紅黴素治療。

  多西環素是非青霉素的一種,及早治療血清轉陰率可達 83%-100%,成為當前治療早期梅毒(梅毒螺旋體感染<2 年,II 期早期梅毒)的主要手段。

  頭孢曲松鈉及苄星青霉素聯合治療梅毒比單一用藥效果好。

  不過,抗生素治療僅對免疫系統正常的患者有效。當患者產生梅毒血清抵抗時,單獨使用青霉素,無論增加劑量還是延長治療時間,都對患者無效。

  梅毒治療后,15%~41% 的患者可能形成梅毒血清固定,使用免疫調節劑再治療梅毒血清固定患者有一定的效果,但存在爭議。

  所以,治療梅毒需要嚴格遵循醫囑,才能達到有效治癒。

  此外,還要保持健康良好的生活方式,防止不安全的性行為。

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

Facebook改進換臉術:無需“投喂”圖片,從視頻里直接變臉

  曉查 發自 凹非寺 
  量子位 報道 公眾號 QbitAI

  近兩年來,Deepfakes 讓許多歐美明星吃盡了苦頭,面對自己的頭像被替換到各種視頻中,卻無能為力。

  比如黑寡婦就對自己的臉被替換到小電影中感到很無奈,呼籲大家停止用 AI 作惡。

  而最近,Facebook 人工智能研究院讓換臉技術再次進化。

  過去 Deepfakes 這項技術需要很多準備材料:一是被替換人臉的原視頻,二是來自換臉人面部各個角度的照片。有這兩樣東西才能造出完美無暇的換臉視頻。

  而來自 Facebook 的技術不需要照片,可以從原視頻直接生成換臉視頻,甚至能對實時視頻進行換臉。

  它讓“大表姐”變得不再熟悉。 

  這項技術的換臉實際上是毫無違和感地修改五官特徵,好讓 AI 無法識別出,因此也就不需要照片了。

  而且 Facebook 的研究人員還表示,這項技術修改后的明星臉仍然可以被人識別出來,但是 AI 卻不行。 

  Facebook 研發這項技術可不是為了換臉好玩,最近因使用人臉識別技術飽受爭議,這家公司希望通過這項新技術來保護用戶的隱私。

  人臉識別和換臉技術對普通民眾的隱私也造成了很大的威脅。比如前一陣大熱的換臉應用 ZAO,讓每個人都享受到換臉帶來的樂趣,但同時也會收集用戶圖片。

  研究人員在論文摘要中說:“人臉識別可能會導致隱私丟失,而換臉技術可能會被用於製作誤導性視頻。”Facebook 用後者來去除視頻中的隱私信息。

  Facebook 聲稱,該技術屬於業內首創,足以抵禦複雜的人臉識別系統。

  Facebook 將在下周韓國首爾舉行的國際計算機視覺國際會議(ICCV)上介紹該工作。

  本周,Facebook 還聯合微軟和亞馬遜,提供 Deepfakes 換臉挑戰數據集,希望能夠提高識別換臉視頻算法的魯棒性,以控制假視頻的傳播。

  此舉頗有些以彼之矛攻彼之盾的意味。

  原文鏈接:

  https://venturebeat.com/2019/10/25/facebook-alters-video-to-make-people-invisible-to-facial-recognition/

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

國家電網預計將於2020年6月前全面實現即插即沖新技術

  作者:JoJo

  【TechWeb】10 月 27 日,近日,國網電動汽車服務有限公司發布了充電服務創新模式“車電服務包”。國網電動汽車公司總經理沈建新表示,國網電動汽車公司將加大車聯網的規模,擴大平台充電樁的數量。同時,國網電動汽車公司將在半年內實現“即插即充、無感支付”在公共場站、專用場站、私人充電樁業務場景全覆蓋,加速布局主要城市充電網絡。

  該措施首先是提供主機廠車電包服務範圍內場景全覆蓋、布局更密集的充電設施服務網絡。 國網目前已建成 9 萬自營充電樁,其中高功率直流快充 6.5 萬根。對此,沈建新表示,未來還將引入更多社會資源,擴大充電樁規模,保證主要城市充電站布點半徑不超過 500 米,同一站點充電等候不超過 30 分鐘,確保充電服務套餐用戶實現區域內充電暢行。

  其次,是加快即插即充、無感支付新技術全覆蓋。2020 年 6 月前,通過技術升級及硬件改造,國網電動汽車公司將完成國網系統充電樁全面支持即插即充,新投入車聯網平台的充電樁全部滿足“即插即充、無感支付”要求,實現“充綠色電,比加油更方便”。

  此次發布的“車電服務包”是與四家車企聯合推出與新車綁定銷售的充電產品,用戶一次付費購買“車電服務包”並綁定車輛后,即可在國網充電樁上享受“即插即充、無感支付”。電動汽車插入充電槍后,充電過程不需要人為干預,自動完成認證、充電啟動、充電停止以及訂單生成與結算,實現了車、樁、網、能源的泛在互聯與高效互動,是國家電網公司泛在電力物聯網建設的典型終端。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

是什麼觸發了宇宙大爆炸?


圖片來源:Christine Daniloff, MIT, ESA/Hubble and NASA

  1.

  根據大爆炸理論,我們的宇宙誕生於 138 億年前,從一個無限小的緻密“火球”,不斷地擴張膨脹,並慢慢冷卻。漸漸地,宇宙中形成了第一批恆星、星系,以及我們如今所見到的所有形式的物質。

  物理學家相信,就在大爆炸將宇宙推向不斷膨脹的進程之前,早期宇宙還經歷了另一個更具爆炸性的階段——宇宙暴脹。這個過程持續的時間不到萬億分之一秒,但膨脹的速度卻是以指數級增長的。  


Guth 的筆記

  上個世紀 80 年代,物理學教授 Alan Guth 首次提出了宇宙膨脹理論,該理論預測宇宙最初是一個極微小的物質點,其大小可能只有質子的千億分之一。這個點中充滿了超高能物質,能量非常之大,以至於內部的壓力產生了一種排斥性的引力——這就是暴脹背後的驅動力。就像火花之於引信一樣,這種引力以前所未有的速度將新生的宇宙向外推,在不到萬億分之一秒的時間內,使宇宙膨脹到接近原始大小的 10²⁷倍。

  許多天文觀測結果都支持了大爆炸和宇宙暴脹理論。但是,這是兩個截然不同的過程,科學家們一直難以理解其中一個是如何緊隨另一個之後出現的。

  在一項新的研究中,物理學家詳細地模擬了早期宇宙中一個可能連接了宇宙暴脹和大爆炸的中間階段。這個階段被稱為“再熱”,這一過程出現在宇宙暴脹末期和大爆炸開始之前的階段,將暴脹產生的冷的、均勻的物質轉變成超熱的、複雜的物質湯。

  論文的作者David Kaiser說:“后暴脹再熱時期為大爆炸創造了條件,在某種意義上,是它啟動了‘爆炸’,正是在這個橋樑時期,所有的事物都開始鬆動,物質的行為變得非常複雜。”

  2.

  對於這個連接了宇宙暴脹和大爆炸的橋樑階段,研究人員很好奇它最初會是什麼樣子。

  Kaiser 說:“再熱的最初階段應該用共振來標記。一種高能物質佔據主導地位,它在廣闊的空間中與自身同步來回擺動,導致爆炸式地產生新的粒子。但這種行為不會永遠持續下去,一旦它開始將能量轉移到另一種形式的物質上,它自身的擺動將在空間中變得更加起伏不平。我們想要測量的是,需要多長的時間共振效應才會破裂,產生的粒子才會彼此分散並且達到某種熱平衡,讓人想起大爆炸發生時的情況。”

  他們的計算機模擬中展示了一個很大的晶格,在這個晶格上,他們繪製了多種形式的物質,並追蹤了當某些條件被改變時,能量和分佈會如何隨之在空間和時間上發生變化。模擬的初始條件是基於一個特定的暴脹模型而設置的,這個模型是一組關於早期宇宙的物質分佈在宇宙暴脹期間的行為得到一系列預測。

  他們之所以選擇這一特定的暴脹模型,是因為它的預測與高精度的宇宙微波背景測量結果非常吻合。

  3.

  在模擬中,他們研究了兩種可能在暴脹期間佔主導地位的物質的行為,這些物質與希格斯玻色子非常相似。

  在進行模擬之前,研究人員對模型中的引力描述進行了一個微小的調整。我們如今看到的普通物質在引力下的作用應正如愛因斯坦廣義相對論中所預測的那樣;但在更高的能量下,比如在宇宙暴脹期間,物質的行為或許會略有不同,與之產生相互作用的引力是由量子力學修正過的。

  在廣義相對論中,引力的強度被表示為一個常數,物理學家稱之為是最小耦合,這意味着,無論一個特定粒子的能量為何,它都會以一個由普適常數所設定的強度對引力效應做出反應。

  然而,在宇宙暴脹的高能量下,物質與引力的相互作用會以一種更為複雜的方式進行。而量子力學效應預測,當與超高能物質發生相互作用時,引力的強度在空間和時間中會發生變化,這是一種被稱為非最小耦合的現象。

  研究人員將這一個非最小耦合項納入了他們的暴脹模型中,並觀察了物質和能量的分佈是如何隨着量子效應的漲落變化的。

  最後他們發現,量子修正過的引力效應對物質的影響越強,宇宙就會越快地從暴脹中寒冷、均勻的物質過渡到更熱、更多樣的大爆炸過程中特有的物質。

  “再熱是一個瘋狂的過程,一切都不受控制。我們發現,當時物質之間的相互作用非常強烈,以至於它可以相應地快速放鬆下來,為大爆炸創造了合適的條件。我們以前並不知道會是這個樣子,但這些都是我們用已知的物理學從模擬中得出的結論。這正是讓我們興奮的地方。”

  對於新的發現,其他物理學家認為,關於造成了暴脹階段的提議有數百種,但從暴脹階段到所謂的‘熱大爆炸’之間的過渡卻是人們最不了解的部分,而這篇論文則通過包含多個獨立的場和複雜的動力學在模型中精確地模擬后暴脹階段,開闢了新的領域。這是極具挑戰性的數值模擬,併為研究早期的宇宙非線性動力學提供了最新的技術。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

挪威嘗試無線電動車充電,面臨雞生蛋、蛋生雞問題

電動車最讓傳統內燃機汽車車主心生疑慮的地方,就是電池續航力不如油箱裡的油讓人安心,半路沒電了,即使來到充電站,不像加油很快就能加滿,充電需要充上好一陣子。為了解決這個電動車發展的障礙,北歐人想到一個好點子,那就是讓電動車可以在馬路上、譬如等紅燈的時候,就能無線充電,這樣電力生生不息,就不怕沒電啦!點子雖好,測試卻遇上了巨大的障礙。

芬蘭國營電力公司芬電(Fortum)原本於 2019 年 3 月時,宣布與挪威首都奧斯陸以及美國公司動量動力(Momentum Dynamics)合作,要嘗試打造 75 千瓦(kilowatt)的無線快速充電基礎設施,初步目標是放在計程車上,因為計程車司機時間就是金錢,不想在充電樁慢慢等充電,但是行駛的里程又較一般車輛更長,不過計程車常會在車站、旅館等處排隊等客,這個等客人的時間,正好用來無線充電。

尤其是北歐國家為了空氣污染等因素鼓勵電動車計程車,以奧斯陸來說,規劃 2023 年要達到計程車「零排放」,也就是要全電動車化,這種基礎設施就更需要了。奧斯陸市積極想發展無線充電技術以說服計程車司機都改為全電動車,因為雖然挪威是全球電動車滲透率最高的國家,但計程車司機仍然大多繼續使用舊的燃油汽車,其中一大原因就是不願意等待充電時間。

奧斯陸市打算先在車站的計程車等客排隊處的路面建設無線充電系統,讓計程車一邊等客一邊充電,當計程車先一步測試無線充電成功,之後,就能推廣到所有車輛,讓每輛電動車都能利用路邊停車時無線充電,或等紅燈時無線充電,再也不用擔心充電問題。

芬電的無線充電系統將由動量動力來製造,設計上只要車輛停到預設的充電處,就可以開始無線充電,系統並內建金屬感應器,以免有鐵鋁罐不小心滾到車底,在無線充電的電磁作用下變熱而發生危險,另外動量動力也計劃安裝生物組織感應器,以免小孩或貓跑到車底受到電磁波影響,目前該系統的充電效率達 94%,與插電充電相差無幾,系統造價則約比傳統充電樁貴上 20%,每個充電點造價 3 萬歐元。不過,成本還不是最大的問題。

計畫仍在紙上談兵階段,將延遲到 2020 年

這個點子就理論上很好,不料執行面卻遇上嚴重問題,導致至今一事無成,問題出在哪?這是個傳統的雞生蛋、蛋生雞問題,那就是:想要無線充電,需要兩方面配合,一方面路面要建立無線充電的基礎建設,這部分奧斯陸市雖然正在計劃進行,但是另一方面,車廠也要打造出能無線充電的電動車,兩方配合才能實現無線充電。但是,沒有基礎建設,車廠打造無線充電車毫無意義,而沒有相對應能無線充電的車,建設基礎建設也毫無意義。

計劃合作的各方找遍了無數車廠,雖然車廠的興趣蠻高,但是相對於要在電動車上添加無線充電模組,這個無線充電模組又只能先在奧斯陸試用,在其他地方是廢鐵一塊,車廠現在的注意力比較著重於如何更順利量產現有電動車之上,尤其是要降低成本,在這個大方向上,要車廠增加成本去添加無線充電模組,可說背道而馳。

這下計畫遇到了困難,要是沒車可適用,打造基礎設施又有何意義呢?當然可以用現有車輛改造,但那就失去前期測試的意義,因為芬電希望測試結果能很快擴散到其他城市,因此使用量產車來測試才有意義。於是計畫只能繼續在紙上談兵階段,目前初步將延遲到 2020 年春季。

奧斯陸市的進行意願仍然很高,無線充電計程車的測試要何時才能開始進行,就得看車廠方面何時能抽出注意力來思考未來車款的無線充電規劃問題了。

(合作媒體:。首圖來源:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

平板收購,iphone手機收購,二手筆電回收,二手iphone收購-全台皆可收購

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

台灣智慧移動產業協會成軍,電動機車將成下一個兆元產業

「台灣智慧移動產業協會」(SMAT) 在 8 月 21 日宣布成立,結合產官學研各界共同推動智慧運輸與乾淨能源,發展電動機車產業。

SMAT 理事長暨中華經濟研究院副院長王健全指出業者紛紛推出新款電動機車,讓 2019 年成為臺灣電動機車產業元年。期待政府能以穩定的政策持續推動產業發展,讓臺灣業者能夠在技術領先的優勢下,成為全球電動機車產業的規格制定者, 並進一步組成臺灣電動機車國家隊,搶下全球兆元市場。

行政院政務委員龔明鑫表示如何讓電動機車產業結合全台灣兩萬多家的機車行將是重要的下一步,政府已經準備好進行全台巡迴,協助機車行轉型,也讓電動機車的生態體系更加完善。立法委員趙天麟則期許 SMAT 的成立能幫助綠能運輸產業的發展,加速改善空氣環境。電動機車可以減少噪音並控制空氣汙染,能降低 PM 排放量達 49 倍。

王健全也宣布將在 9 月發表首本「 台灣電動機車產業發展白皮書」,並搶先透露白皮書的亮點。白皮書主要由工研院產業科技國際策略發展所協助撰寫,工研院指出台灣有 50 年的機車製造經驗,也是全球重要的電子產品生產國, 在兩大產業皆具備完整的研發、生產與供應鏈管理能力 。2018 年新售電動機車已佔總體機車的 11%,2019 年電動機車整車產值更可望達到 110 億元。白皮書也指出台灣在普通重型電動機車領域領先全球 3 到 5 年,未來有機會能成為下一個兆元產業。

大數據股份有限公司利用大數據網路分析與消費者民意調查,了解台灣消費者對電動機車的態度。大數據營運長林慧珍分析指出,消費者選購電動機車的三大原因是購車補助、追求環保和換電的便利性。調查發現電動機車的消費者和潛在消費者多數為年收入 60 萬人以下的民眾,因此對價格較為敏感。消費者有高達 94% 在意政府補助,67.7% 的民眾對政府補助的金額感到滿意,顯示電動機車的發展還很需要政府補助的支持。此外,64.3% 的使用者滿意換電,但僅有 42.8% 的使用者滿意充電,顯示主流消費者更偏好換電模式。

(合作媒體:。首圖來源:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

收購3c,收購IPHONE,收購蘋果電腦-詳細收購流程一覽表

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※高價收購3C產品,價格不怕你比較

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

Gogoro 發表 Gogoro S2 ABS,光譜靛新色登場

Gogoro 推出了 Gogoro S2 系列的新車 Gogoro S2 ABS,首度在 Gogoro S2 車款上引進 ABS(Anti-Lock Brake System) 防鎖死煞車系統。

Gogoro S2 ABS 最大的特色在於前後輪都搭載重車等級 BOSCH ABS 10 雙迴路煞車系統,煞車時系統會以每秒 200 次的高頻率監測前後輪轉動狀況,在車輪即將鎖死的瞬間自動釋放煞車,避免車輪在緊急煞車時鎖死。 Bosch ABS 10 雙迴路煞車系統重量僅 580 克,在僅少量提升車重的狀況下提升穩定性和操控性能。

Gogoro 也與 MAXXIS 攜手研發 Gogoro S2 ABS 獨家的 ABS 性能胎,在雨天濕滑路面時更能有效發揮 ABS 系統的制動性,讓用戶騎乘更加安全。獨特的顏色也是一大亮點,Gogoro S2 ABS 車身運用多層次染色的超細緻顆粒珍珠漆,打造出新色光譜靛,車體顏色會隨著光線角度產生變化。此外,Gogoro S2 ABS 也調整了 USB 插孔的位置,移到左把手的下方。

Gogoro S2 ABS。

搭載重車等級 BOSCH ABS 10 雙迴路煞車系統是 Gogoro S2 ABS 的最大特色。

Gogoro S2 ABS 的 USB 插孔位於左邊把手的下方。

Gogoro S2 ABS 使用 iQ System 智慧鑰匙卡靠近 S 標誌解鎖。

Gogoro S2 ABS 安全極速達到時速 92 公里,最大功率為 7.6 kW,靜止加速到時速 50 公里僅需 3.8 秒。Gogoro S2 ABS 時速 40 公里之下單次換電續航里程為 110 公里,時速 30 公里時單次換電續航里程則為 150 公里。 空車重量為 105 公斤,加上電池則為 123 公斤,擁有 25L 的置物空間。

Gogoro S2 ABS 僅有光譜靛一款顏色,定價為 101,980 元台幣,補助最高的雲林縣汰換二行程機車換購電動機車補助最高 30,000 元,最低台幣 71,980 元起,即日起正式上市。購買 Gogoro S2 全車系任一車款,加贈市價約台幣 6,800 元的限量 ROAV 聯名墨鏡。

(合作媒體:。圖片來源:)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※高價3c回收,收購空拍機,收購鏡頭,收購 MACBOOK-更多收購平台討論專區

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

收購3c瘋!各款手機、筆電、相機、平板,歡迎來詢價!

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

長慶油田發現10億噸級大油田

  科技日報訊 (杜英)“長慶油田在甘肅慶陽勘探發現了儲量 10 億噸級的慶城大油田,慶城油田目前已建成百萬噸級生產能力。”10 月 25 日,中國石油天然氣股份有限公司長慶油田分公司對外發布了這一消息。

  資料显示,2018 年全國生產原油是 1.89 億噸,而慶城大油田新增地質儲量合計達 10.51 億噸。“我國原油對外依存度 2018 年已突破 70%,儲量規模 10 億噸級慶城油田的發現,在未來3—4 年內將建成 300 萬噸的生產能力,相當於又給國家建成一个中型油田。”長慶油田公司新聞發言人李逵表示,新油田的發現對支撐長慶油田保障國家油氣安全戰略將發揮重要作用。

  “此次勘探獲得重大突破,得益於長慶油田對鄂爾多斯盆地石油勘探地質理論和三維地震、成像測井技術不斷創新,更源於水平井優快鑽井、水力加砂壓裂核心技術的突破。”長慶油田分公司副總經理付金華說。自 2011 年始,長慶油田開展了近十年的非常規石油勘探地質理論創新、工藝核心配套技術攻關及水平井試驗區建設。近兩年來,通過持續加強儲層緻密機理與成藏機理和富集規律等關鍵科技問題攻關,明確了長 7 源內油藏形成機理受控於穩定構造背景;建立了長 7 油藏“四控”富集模式;形成了對長 7 石油資源宏觀、立體、全方位的新認識,形成了長 7 油藏規模勘探、效益開發的地質理論,“十年磨一劍,長慶油田終於打開了非常規資源的寶庫。”付金華表示。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

3c收購,鏡頭 收購有可能以全新價回收嗎?

台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

賣IPHONE,iPhone回收,舊換新!教你怎麼賣才划算?