續航里程翻倍 日產2017年推下一代聆風純電動車

據《美國汽車新聞》日前報道,日產(Nissan)汽車計劃2017年推出下一代聆風純電動車,從電池組和外觀設計等角度改進新車,使續航里程比當前的聆風增加一倍以上,達到300千米左右。2010年12月發佈的聆風車型,迄今仍是累計銷量最高的純電動車型之一。

此外,英菲尼迪豪華品牌一款被延遲進度的電動車也將在2017年年初亮相,搭載改進的電池組。而英菲尼迪電動車由於電池組尺寸更大,續航里程將超過聆風。

新的電池化學成分

日產負責零排放新能源車和英菲尼迪業務的執行副總裁安迪•帕默(Andy Palmer)在今年北京車展上透露,2017年將展出一種新的電池化學成分,用於日產和英菲尼迪電動車。

帕默沒有給出新一代聆風的續航里程目標值,但暗示電動車電池應當能夠支援300千米或186英里的續航里程,原因是當前氫燃料電池車等其他競爭對手也在研發中,而由於電池能量密度的天生缺陷,續航里程不及燃料電池車,亟待改進。

根據美國環保署EPA數據,聆風上市時按照EPA標準的一次充電續航里程為73英里(117.5千米),2014年款車型提高到84英里(135.2千米)。改進主要是由於應用了效率更高的熱系統。如果下一代聆風實現300千米續航里程,則將被現款車型提高一倍以上。

外觀設計主流化

另外,日產認為電動車外形應該貼近大眾審美。未來聆風將保留當前的掀背佈局,但外形線條將更加流暢,符合主流汽車設計。下一代聆風將仍然帶有一些電動車外觀特徵,例如沒有進氣隔柵孔隙。然而該車將更加接近日產品牌創新的設計語言。

日產品牌全球設計總監衛青木(Mamoru Aoki)表示,電動車不應該只是通過外觀上的特殊性來吸引注意力,其列舉特斯拉Model S轎車作為例證,「當前聆風過於追求電動車特有的外觀。特斯拉則看起來並不像(典型的)電動車。Model S外形美觀、富有運動感、線條流暢,並且具備真實感(指接近常規車輛)。」

日產首席創意官中村史郎(Shiro Nakamura)透露,新一代聆風將採用該品牌新V Motion設計特點,和新款Rogue(即奇駿北美版)上的V形前臉和浮頂。

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

【其他文章推薦】

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

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

新北清潔公司,居家、辦公、裝潢細清專業服務

※推薦評價好的iphone維修中心

豐田終止特斯拉供應合約 轉投燃料電池科技

據MoneyDJ 報導,豐田汽車(Toyota)不看好電動車,壓寶燃料電池科技,因此12日宣佈該公司和特斯拉(Tesla)的電動車電池供應協定今年到期之後,不會續約,將專注全力研發四門燃料電池車,計畫明年在美國加州發表,同時也將發展加氫站,支援燃料電池科技。

2010年豐田對特斯拉投資5,000萬美元,取得3%股份;2011年雙方更簽訂1億美元合作協議,同意豐田的RAV4電動車部份採用特斯拉電池和發動機;當時雙方樂觀預期,RAV4可望開啟更廣泛的合作關係。不料基本售價49,800美元的RAV4電動車推出後,銷售奇慘無比,豐田極力促銷也無力回天。

因此,豐田高層逐漸認為燃料電池才是環保車的發展方向,與主打電動車的特斯拉漸行漸遠。

日經新聞今年3月報導,豐田預計在2015年開賣的燃料電池車售價將壓在1,000萬日圓以下,之後並計劃於2020年代將售價壓低至300-500萬日圓的水準。本田汽車(Honda)也將在2015年11月在狹山工廠生產燃料電池車。

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

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

特拉斯將建超大電池廠 滿足電動車市場需求

電動車廠商特斯拉的執行長Elon Musk本周三(14日)於世界能源創新論壇上指出,為滿足電動車的電池市場需求,將與Panasonic等合作夥伴共同打造超大電池廠(Gigafactory)。   本年度的世界能源創新論壇於特斯拉加州費力蒙廠舉行。Musk表示,公司原本預期超大電池廠(Gigafactory)只能將鋰電池的成本壓低30%,但垂直整合供應鏈有機會進一步壓低成本。他還認為,電池的需求日益上升,光是滿足汽車業者的需求,估計就得打造兩百座超大電池廠。   Musk在論壇中指出,為了完成大眾電動車在三年內量產的目標,特斯拉計劃與Panasonic等合作夥伴共同打造超大電池廠,建廠地點即將拍板定案。彭博社報導, Musk表示每座超大電池廠的建造成本將高達五十億美元。   除了供應特斯拉電動車的需求之外,這些超大電池廠還將為美國太陽能廠SolarCity,亦即該公司的關係企業提供固定式電源儲存裝置。在首座超大電池廠開始投產的第一年(2017年底),預計就能將電池模組的每度成本減少30%以上;在2020年產能全開之際,超大電池廠的鋰電池年產量就會超過2013年全球製造的鋰電池總量。

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

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

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

※別再煩惱如何寫文案,掌握八大原則!

Panasonic將獨攬特斯拉Gigafactory訂單

Panasonic Corp.宣稱預料會成為特斯拉耗資數十億美元超大鋰電池廠Gigafactory的唯一供應商。   路透社報導,Panasonic資深執行經理兼汽車暨工業部總裁Yoshio Ito表示,特斯拉、Panasonic正在洽談Gigafactory的投資細節,接下來則會商談興建計畫。他說,目前應該不會有其他電池對手來競標,但就算Panasonic成為Gigafactory的唯一供應商,該公司也不會獨力承擔大多數的投資責任。   另外,Ito也指出,需求不可能一下子跳增10倍,因此Panasonic認為緩步執行投資計畫應是正確決定。 Panasonic今年對車用電池將投入超過280億日圓(2.75億美元)、比目前預算高出一倍,大多數將用來擴充供應特斯拉的日本小型鋰電池廠產能。   特斯拉、Panasonic曾於去年10月敲定協議,至2017年為止的四年期間,Panasonic將供應特斯拉近20億顆電池,遠高於過去兩年供應的2億顆。

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

【其他文章推薦】

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

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

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

南投搬家公司費用需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

※教你寫出一流的銷售文案?

中國國際汽車商品交易會-中國國際新能源汽車主題展覽

展覽日期: 2014年10月19-21日   展覽地點: 上海虹橋 中國博覽會會展綜合體 展覽週期: 每年一屆 展出面積: 100000平方米

舉辦單位: 中華人民共和國商務部 主辦單位: 中國通用技術集團  

CIAPE—新能源汽車正步入行業發展的“春天”

  兩會期間,新能源汽車再次成為熱點話題, 國務院總理李克強在今年的《政府工作報告》中也提出“發展新能源汽車是政府治理環境、提升行業競爭力的重要方針”。新能源汽車板塊已然成為2014年伊始的投資熱點。扶持政策加碼、海外市場特斯拉的明星效應、國內消費者加大關注等多種因素的合力下,可以說,新能源汽車正步入行業發展的“春天”。業界普遍認為,這一調整符合市場預期,顯示了政府的支援力度。伴隨著對新能源汽車的政策扶持,也將給電池產業、電池電機上游的鋰和稀土資源行業、充電站行業、乘用車企業帶來更大的機遇。並帶動產業鏈相關企業和業務快速發展。   為順應綠色交通的發展潮流,積極貫徹回應國家的相關政策,3月17日,上海市出臺《上海市新能源汽車推廣應用實施方案(2013-2015年)》,計畫到2015年推廣應用13000輛新能源汽車。對於新能源補貼政策力度更大,不僅提供了車牌和現金的雙重補貼,還將進一步把補貼範圍擴大到插電式混合動力車型。在此良好背景下,新能源汽車主題展覽做為“中國國際汽車商品交易會”主題展於10月19-21日在上海中國展覽會會展綜合體舉行。

CIAPE—展品範圍

新能源汽車(乘用車/商用車):純電動車:轎車、大巴、公車、各型旅行車、各種純電動特種車(環衛車、電力車、郵政車、小型客貨車、高爾夫車、房車、叉車、搬運車、牽引車、旅遊觀光車、醫療車、警用車、摩托車、三輪車等);混合動力車:轎車、大巴、公車、各型旅行車等;其他能源車:燃料電池、氫能、生物燃料、太陽能、天然氣等各種新能源、清潔燃料及低排放、環保節能型車;
動力驅動系統:動力電池、電池管理系統、燃料電池、混合動力系統、驅動電機、電動車控制及驅動系統、發動機、檢測修復設備、有關的測試、監控、防護儀器 、相關技術; 
新能源汽車零部件:電力電容器、超級電容器、飛輪、電熱泵 、電動助力轉向 、電動空調 、輪胎、線連接 、電磁技術、相關材料; 


充電設施:充電站智慧型網路專案規劃及成果展示、加油站擴建充(換)電站、加油充電綜合服務站展示、逆變器、太陽能、風能互補新能源汽車充電站技術產品、充電站配電設備、充電機、電能監控系統、有源濾波裝臵、充電樁、變壓器、配電櫃、電纜、直接充電設備、管理輔助設備 、充換電池及電池管理系統、停車場充電設施、智慧監控 、充電站供電解決方案 、充電站-智慧電網解決方案: 

汽車設計:整車設計,系統控制設計等
機動車污染控制與節能新產品:機動車節能減排動力系統及產品、尾氣淨化及排氣後處理技術與設備、噪音污染控制技術及產品、廢氣再迴圈裝置、燃油蒸發回收裝置、節能環保修復技術與設備、節油技術及產品、機動車節能減排檢驗、測試技術、設備及產品等。
天然氣汽車及加氣站設備:天然氣汽車:天然氣乘用車、天然氣商用車、天然氣專用車、天然氣、柴油雙燃料汽車、深冷液化天然氣汽車、煤層氣汽車、天然氣運輸車、相關零部件等;加氣站設備及相關配套產品等。

CIAPE—高水準的同期活動 

將邀請來自世界範圍內的專家、學者及行業管理者展開演講和有針對性的研討。論壇期間將舉辦項目洽談會,集中發佈各地政府及產業園區、企業招商引資專案與資訊,發佈新能源汽車領域新車型、新技術、新動態,邀請到新能源汽車試點城市的政府官員、主管機構負責人、新能源汽車相關企業、電動汽車充(換)電站相關企業及金融投資機構對接洽談項目。為參展商和採購商提供寬領域、深層次的增值服務。

CIAPE—媒體報導

CIAPE 還得到了包括新華社、人民日報、中央電視臺、中國日報、環球時報、21 世紀經濟報導、國際商報、華盛頓郵報、亞洲中心時報、路透社、日本經濟新聞社、新浪、網易、搜狐、騰訊、中國汽車報、慧聰網、蓋世汽車網等300 餘家國內外媒體的廣泛關注和報導。


更多詳情請流覽交易會官方網站
組委會聯繫方式 電  話:0086 -10 -52338018  89501118

傳  真:0086 -10 -62500724

連絡人:文 玉 13522289650

郵  箱:

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

【其他文章推薦】

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

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

※別再煩惱如何寫文案,掌握八大原則!

特斯拉技術長:汽車市場誠可貴,能源儲存價更高

電動車大廠特斯拉(Tesla)的技術長JB‧史朝保(JB Straubel),於2014 年5 月「合資矽谷」(Joint Venture Silicon Valley )論壇所舉辦的能源儲存座談會(energy storage symposium)上,談論電池科技、Giga factory,以及電網能源儲存,也透露了眾所矚目的特斯拉未來走向。

JB‧史朝保表示,他真的很喜愛電池技術,喜愛電池更勝於汽車。他指出1990 年代電動車的基礎是鉛酸電池,而鋰電池的成熟,不論在能量密度,或是充放電循環壽命上,都遠遠勝過鉛酸電池,成為改變電動車產業情勢的關鍵,也成為特斯拉之所以能出現的關鍵主因。2003 年,無人發展鋰電池車,到如今,2014 年,幾乎所有主要車廠都有鋰電池車的規劃,JB‧史朝保說這10 年來的變化實在是相當讓人驚奇。

JB‧史朝保談起2008 年特斯拉推出的Roadster,內建容量50 度電的電池組,當時是驚世之作,不過現在看來已經是過氣的科技,5 年來,從Roadster 到Model S,電池的效能提升了40%,過去10 年來,電池的能量密度倍增,而且電池能量密度的上升曲線還沒有來到高原期。

談到特斯拉近來最受世人矚目的Giga factory,JB‧史朝保說,不需要太多計算,就能察覺當每年出貨50 萬輛第三代電動車時,將會增加上百萬度的電池需求,特斯拉預期本身將會有3 到4 百萬度的需求,佔去10% 全球電池生產規模,而Giga factory 則是「在單一工廠內,倍增全球電池生產能量,並創新整個供應鏈」,以大為降低鋰電池的生產成本。

但是正如JB‧史朝保本人「喜愛電池更勝於汽車」,Giga factory 的目標並不只限於供應特斯拉的電動車,他表示Giga factory 有3,500 萬度的生產規模將用於供應特斯拉的電動車工廠,但有1,500 萬度,則將用於固定式的能源儲存電池組,JB‧史朝保認為「或許整個產業界看能源儲存的市場規模,都看得不夠大」,他更看好能源儲存的市場會成長的比電動車還要更快,而在能源儲存領域,他認為鋰電池技術在未來5 到10 年內仍然會是主流。

在特斯拉宣布興建Giga factory 的計畫之後,許多分析機構都認為特斯拉已經不再只是電動車廠,而是能源儲存大廠,JB‧史朝保也正式肯定了這種看法,表示特斯拉「不僅是汽車公司,也是能源創新企業」。以特斯拉自己的費利蒙(Fremont)工廠來說,自2013 年起,工廠內就內建2,000 度的電池組,調控10% 的尖峰負載,而這還只是相對小規模,特斯拉計畫在3 到4 個月內將規模擴增一倍為4,000 度。

而能源儲存所需的電池,在各方面的要求遠比車用電池低,例如不用擔心振動、緊急剎車時的安全性、高熱下行駛,或是充電速度等等問題,因此能源儲存所需的電池,在設計製造上都比較容易,JB‧史朝保更認為能源儲存市場會成長得「遠比世人所認為的更快」,只不過目前市場的商業模式未定,許多條件尚未完全成熟而已。

從特斯拉技術長的談話,可以明白了解特斯拉總體策略已經跨出汽車領域,將積極啃食能源儲存大餅。目前以紐約州與夏威夷州為首的美國各州,積極發展分散式能源及能源儲存,紐約地鐵更率先實驗液流電池能源儲存,德國因政策因素,也使得不論是住宅或是工商業,都積極邁向自有能源,第三世界國家廣大無電網地區也正發展分散式能源及能源儲存,使得能源儲存市場潛力無限。

特斯拉高舉鋰電池技術,強力進入此一領域,將與奇異(GE)「獨拉松」(Durathon)鈉鎳鹵化物電池、鈉硫電池、液流電池、液態金屬電池等競爭對手直接競爭,更不僅電池對手,包括飛輪、壓縮空氣儲能(所謂「風穴」)等等儲能技術也一樣身在火線上,一場能源儲存技術大戰可說山雨欲來。

 

本文全文授權自《》──〈〉

圖片來源:Commons Wiki

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

【其他文章推薦】

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

【asp.net core 系列】13 Identity 身份驗證入門

0. 前言

通過前兩篇我們實現了如何在Service層如何訪問數據,以及如何運用簡單的加密算法對數據加密。這一篇我們將探索如何實現asp.net core的身份驗證。

1. 身份驗證

asp.net core的身份驗證有 JwtBearer和Cookie兩種常見的模式,在這一篇我們將啟用Cookie作為身份信息的保存。那麼,我們如何啟用呢?

在Startup.cs 的ConfigureServices(IServiceCollection services) 方法里添加如下:

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
                .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, options =>
                {
                    Configuration.Bind("CookieSettings",options);
                });

此時可以啟動一個權限驗證,當用戶訪問需要驗證的頁面或接口時,如果沒有登錄,則會自動跳轉到:

https://localhost:5001/Account/Login?ReturnUrl=XXXX

其中ReturnUrl指向來源頁。

1.1 設置驗證

當我們在Startup類里設置啟用了身份驗證后,並不是訪問所有接口都會被跳轉到登錄頁面。那麼如何設置訪問的路徑需要身份驗證呢?asp.net core為我們提供了一個特性類:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
public class AuthorizeAttribute : Attribute, IAuthorizeData
{
    public string Policy { get; set; }
    public string Roles { get; set; }
    public string AuthenticationSchemes { get; set; }
}

可以看的出,這個特性類允許設置在類、方法上,可以設置多個,允許子類繼承父類的特性。所以可以在控制器上設置[Authorize],當在控制器上設置以後訪問控制器里所有的Action都會要求驗證身份;也可以單獨設置在Action上,表示該Action需要驗證身份,控制器里的其他方法不需要驗證。

1.2 設置忽略

我們在開發過程中,會遇到這樣的一組鏈接或者頁面:請求地址同屬於一個控制器下,但其中某個地址可以不用用戶登錄就可以訪問。通常我們為了減少重複代碼以及復用性等方面的考慮,會直接在控制器上設置身份驗證要求,而不是在控制器里所有的Action上添加驗證要求。

那麼,我們如何放開其中的某個請求,可以允許它不用身份驗證。

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public class AllowAnonymousAttribute : Attribute, IAllowAnonymous
{
}

仔細觀察,可以看得出這個特性可以設置在類、方法上,不允許多次設置,允許子類繼承父類的特性。

這個特性的使用沒啥可說的,不過需要注意的是,不要與AuthorizeAttribute一起使用。雖然編譯上沒啥問題,但實際上會對程序員的邏輯照成一定程度的誤導。

2.保存身份

有身份驗證,就必然需要保存身份。當我們從數據庫中或者其他的三方服務中獲取到用戶信息后,我們需要將用戶信息保存起來,而不是每次都向用戶或者服務提供方索求信息。

在asp.net core中,Controller類里有一個屬性:

public HttpContext HttpContext { get; }

HttpContext 提供了一個擴展方法,可以用來保存用戶信息:

public static Task SignInAsync(this HttpContext context, ClaimsPrincipal principal);

暫時忽略這個方法的返回類型,它接受了一個ClaimsPrincipal類型的參數。我們來看下這個類的基本情況吧:

public class ClaimsPrincipal : IPrincipal
{

    public ClaimsPrincipal();
    public ClaimsPrincipal(IEnumerable<ClaimsIdentity> identities);
    public ClaimsPrincipal(BinaryReader reader);
    public ClaimsPrincipal(IIdentity identity);
    public ClaimsPrincipal(IPrincipal principal);
    
    public static ClaimsPrincipal Current { get; }
    public static Func<ClaimsPrincipal> ClaimsPrincipalSelector { get; set; }
    public static Func<IEnumerable<ClaimsIdentity>, ClaimsIdentity> PrimaryIdentitySelector { get; set; }
    public virtual IIdentity Identity { get; }
    public virtual IEnumerable<ClaimsIdentity> Identities { get; }
    public virtual IEnumerable<Claim> Claims { get; }
    public virtual void AddIdentities(IEnumerable<ClaimsIdentity> identities);
    public virtual void AddIdentity(ClaimsIdentity identity);
    public virtual ClaimsPrincipal Clone();
    public virtual IEnumerable<Claim> FindAll(Predicate<Claim> match);
    public virtual IEnumerable<Claim> FindAll(string type);
    public virtual Claim FindFirst(string type);
    public virtual Claim FindFirst(Predicate<Claim> match);
    public virtual bool HasClaim(Predicate<Claim> match);
    public virtual bool HasClaim(string type, string value);
    public virtual bool IsInRole(string role);
    public virtual void WriteTo(BinaryWriter writer);
}

方法和屬性有點多,那麼我們重點關注一下構造函數以及可以AddXXX開頭的方法。

這裡有一個竅門,對於一個陌生的類來說,構造函數對於類本身是個很重要的特徵,我們可以通過構造函數分析出這個類需要哪些基礎數據。

所以,通過簡單的分析,我們需要繼續了解這兩個類:

public class ClaimsIdentity : IIdentity
{
    public ClaimsIdentity();
    public ClaimsIdentity(string authenticationType);
    public ClaimsIdentity(IIdentity identity);
    public ClaimsIdentity(IEnumerable<Claim> claims);
    public ClaimsIdentity(IEnumerable<Claim> claims, string authenticationType);
    public ClaimsIdentity(IIdentity identity, IEnumerable<Claim> claims);
    public ClaimsIdentity(string authenticationType, string nameType, string roleType);
    public ClaimsIdentity(IEnumerable<Claim> claims, string authenticationType, string nameType, string roleType);
    public ClaimsIdentity(IIdentity identity, IEnumerable<Claim> claims, string authenticationType, string nameType, string roleType);
    
}

public class Claim
{
    public Claim(BinaryReader reader);
    public Claim(BinaryReader reader, ClaimsIdentity subject);

    public Claim(string type, string value);
    public Claim(string type, string value, string valueType);
    public Claim(string type, string value, string valueType, string issuer);

    public Claim(string type, string value, string valueType, string issuer, string originalIssuer);
    public Claim(string type, string value, string valueType, string issuer, string originalIssuer, ClaimsIdentity subject);
    protected Claim(Claim other);
    protected Claim(Claim other, ClaimsIdentity subject);
    public string Type { get; }
    public ClaimsIdentity Subject { get; }
    public IDictionary<string, string> Properties { get; }
    public string OriginalIssuer { get; }
    public string Issuer { get; }
    public string ValueType { get; }
    public string Value { get; }
    protected virtual byte[] CustomSerializationData { get; }
    public virtual Claim Clone();
    public virtual Claim Clone(ClaimsIdentity identity);
    public override string ToString();
    public virtual void WriteTo(BinaryWriter writer);
    protected virtual void WriteTo(BinaryWriter writer, byte[] userData);
}

所以,看到這裏就會發現,我們可以通過以下方式保存信息:

List<Claim> claims = null;
var identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);

HttpContext.SignInAsync( CookieAuthenticationDefaults.AuthenticationScheme,new ClaimsPrincipal(identity));

這時候,數據就可以保存在Cookie里了,那麼如何在控制器中獲取到數據呢:

public ClaimsPrincipal User { get; }

在控制器中,提供了這樣一個屬性,當然如果想要正確獲取到值的話,需要在 Startup.cs類中的添加如下配置:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // ……省略其他配置
    app.UseAuthorization();
    app.UseAuthentication();
    // ……省略其他配置
}

3. 總結

在這一篇中,簡單介紹了asp.net core的identity,下一篇將從實際上帶領大家設置不一樣的identity以及Authorize驗證。

更多內容煩請關注我的博客《高先生小屋》

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

新北清潔公司,居家、辦公、裝潢細清專業服務

※推薦評價好的iphone維修中心

最詳細教學–win10 + frp + rdpwrap + 阿里雲服務器 –實現win10 多用戶同時遠程登錄內網機

概述:

  使用win10 專業版 + frp + RDPwrap + 阿里雲服務器 的組合實現win10 多用戶同時遠程登錄內網機。使用frp 做內網穿透,將內網機的指定端口暴露在外網,通過ip+port 來實現遠程登錄。再使用rdpwrap 來破解win10 不能同時多用戶登錄的問題。

 

 

設想一下場景

  我是一個建築工程師。經常出差,需要經常畫3D圖和展示建築圖紙,所以買了一台性能非常強的筆記本工作站。筆記本重量大概3.9kg,充電器0.5kg,一個本子,一個書包,全部加起來接近10斤的重量。每天背着10斤重的東西跑來跑去出差,想想都累!!!

  筆記本工作站不僅重,價格也很貴,非常不方便用於出差,那簡直是折磨。。。。。。

   被折磨幾個月後,他開始向他的一個朋友訴苦,這真的是太t*d痛苦了,我能不能背着一台輕薄本筆記本出差啊,可是性能又要很好才行,怎麼辦???

然後就有了這篇文章。

 

以↑純屬扯淡……

—————————————————我是完美分隔符—————————————————

一、先實現單用戶遠程登錄內網機

 1.為什麼要實現內網穿透

    繼續對話:

    你怎麼在互聯網裡面找到你家裡面的電腦,是不是要把你的電腦與互聯網對接上。

    是啊,對接上啦,我的電腦不是連着網線嗎……

    (我語文水平有問題……。)兩個條件:一是你的電腦與互聯網對接上,二是讓互聯網知道你家在哪裡,不,你的電腦在哪裡。

    明白,好的。那什麼是內網穿透啊?

    額,(心想:md還要給你解釋內網外網……還要幫你弄,還免費的,我還有一堆事要忙啊,si建築的)。

    enenen……我幫你弄好就行了,你看百度吧,給個鏈接你:https://baike.baidu.com/item/%E5%86%85%E7%BD%91%E7%A9%BF%E9%80%8F

    (這不是本文的重點)

 2.要準備什麼呢

電腦若干台……
雲服務器(比如阿里雲服務器)
frp 反向代理工具(免費簡單高效)

 資源下載路徑>>>

   window端frp下載:https://github.com/fatedier/frp/releases/download/v0.30.0/frp_0.30.0_windows_amd64.zip

   linux端frp 下載:https://github.com/fatedier/frp/releases/download/v0.30.0/frp_0.30.0_linux_amd64.tar.gz

   資源解壓后的模樣>>>

      windows 解壓后                                                               linux  解壓后

                               

  

先上草圖過過目: 

 

 3.配置過程

      單用戶遠程登錄內網機需要配置的東東:

  1. windows下的frp客戶端:frpc
  2. linux的frp服務端:frps;
  3. 阿里雲服務器端口開放;
  4. windows的遠程登錄配置;
  5. 啟動window中的frpc 客戶端的命令:客戶端連接服務;
  6. 開啟另外一台windows電腦,準備遠程連接測試

 

   1) win 配置frpc.ini 文件(是 frpc ,是客戶端,別配錯了)

[common]
server_addr = 11.11.11.11
server_port = 7000

# trace, debug, info, warn, error
log_level = trace

#遠程桌面
[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 3389
remote_port = 6000

 

  2)Linux 配置frps.ini 文件 (服務端)

[common]
bind_port = 7000
vhost_http_port=8080

  啟動linux中的frps 服務的命令:啟動服務

當前窗口啟動,關閉窗口失效: ./frps -c frps.ini
後台啟動,關閉窗口依然有效:nohup ./frps -c frps.ini &

  啟動成功的效果分別是>>>

   

   

          第二張圖片里的 [1] 2374 是什麼???   

           輸入命令:kill 2374   就知道了……

 

  3)打開阿里雲服務器端口

    進入:安全組配置

 

   進入:安全組列表>配置規則

 

    開放端口:6000和7000

 

   阿里雲實例:重啟

   

  4)配置windows 遠程登錄用戶

     右鍵“我的電腦”進入這個界面    選擇“遠程設置”

     

 

      允許遠程連接

      

   

      點“添加”進入, >>>  “高級”  >>> “立即查找”  >>> 選擇用戶,用於遠程登錄

     

 

    PS: 對於win10 家庭版的用戶,遠程設置的界面是這樣子的

    

     對於win家庭版的用戶,將破解多用戶遠程登錄提前先做: 跳轉

 

  5)啟動window中的frpc 客戶端的命令:客戶端連接服務

打開cmd窗口:
先cd 到:frpc.exe 執行程序的目錄
再執行: frpc.exe -c frpc.ini

  啟動成功的效果圖>>> 簡單的描述一下

       

 

   6)開啟另外一台windows電腦,準備遠程連接測試

     快速打開遠程連接窗口:win + R   >>>  輸入:mstsc      再確定

     

 

     最激動人心的時刻到了

      

      遠程登錄輸入用戶密碼

      

 

     有這個界面說明成功了       點進去

      

 

 

     到目前為止單用戶遠程登錄已完成!!!

      

比如一台高性能的電腦只能同時給一個人用,那太浪費了;

又比如另一個人要用你賬號登錄時還要問你:親,你在在用XXX電腦嗎;

再比如多個人同時用一個賬號遠程登錄時:哪個親在用,不用的人不出聲回復你,正在用的人可能沒聽到,你就尷尬吧/(ㄒoㄒ)/~~

最後比如有個人正在使用,你一聲不吭登錄了,咔嚓,m蛋那個gou兒子登錄不說…………………………

繼續學習,解決問題>>> 

二、多用戶同時遠程登錄內網機

       多用戶同時遠程登錄內網機需要做的那些事:

  1. 單用戶遠程登錄成功;
  2. 新建一個windows登錄用戶;
  3. 配置windows遠程登錄用戶;
  4. 編輯本地組策略:配置關於遠程登錄的東東;
  5. 解決windows多用戶同時登錄的問題;
  6. 測試遠程登錄。

   

1)單用戶遠程登錄成功

      前提:在你 單用戶遠程登錄成功后再做多用戶同時遠程登錄。

 

2)新建一個windows登錄用戶

    直接搜索:“用戶”,進入“創建標準用戶賬戶”

       

 

 

 

 輸入新用戶信息:ccccc  隨便輸入你喜歡的

 

 

   ps:當你點擊創建時,輸入框數據會被清空,其實已經創建好了,只是win10 沒有自動幫你關窗口,也許是方便創建多個用戶吧,個人覺得體驗感很差。

   雙擊打開:用戶  >>> 可以看到有啦

  

 

  

3)配置windows遠程登錄用戶

    將剛才新建的用戶添加到遠程登錄(上面已經講過了)

   

    添加成功:

   

 

4)編輯本地組策略

     win + R  >>>  輸入 ”gpedit.msc“ 

     

       打開本地組策略

      

 

      進入到遠程登錄配置

     

 

       配置連接數和同時遠程登錄的信息  

     

        PS: windows 雖然允許設置多用戶同時遠程登錄,但不允許你這麼遠程連接……

        配置完這個后的效果:先遠程登錄一個用戶,再遠程登錄另外一個用戶時會提示等待前一個用戶退出。

         可自行驗證,在這裏就不演示了。

        

 

 5)解決windows多用戶同時登錄的問題

     先下載:RDPWrap-v1.6   https://github.com/stascorp/rdpwrap/releases/tag/v1.6.2

   

 

      解壓后:

     

    1. 先再cmd 下 執行“install.bat” 安裝RDPWrap ;安裝成功后,在“C:\Program Files\RDP Wrapper” 目錄下有

     

 

    2. 再嘗試執行下update.bat 。更新不了配置信息,需要手動來配置

      在配置rdpwrap.ini 之前先看下電腦版本:win + r   ,接着輸入:ver (細心的小夥伴會看到,打開cmd其實就已經看到了版本:10.0.18362.53 )

     

 

     接着打開 C:\Program Files\RDP Wrapper\rdpwrap.ini ,在文本末尾添加面的配置信息(不同版本的配置不一樣)     配置之間有空行,最後的空行也不要漏了

[10.0.18362.53]
LocalOnlyPatch.x86=1
LocalOnlyOffset.x86=B7D06
LocalOnlyCode.x86=jmpshort
LocalOnlyPatch.x64=1
LocalOnlyOffset.x64=82FB5
LocalOnlyCode.x64=jmpshort
SingleUserPatch.x86=1
SingleUserOffset.x86=50535
SingleUserCode.x86=nop
SingleUserPatch.x64=1
SingleUserOffset.x64=DBFC
SingleUserCode.x64=Zero
DefPolicyPatch.x86=1
DefPolicyOffset.x86=50269
DefPolicyCode.x86=CDefPolicy_Query_eax_ecx
DefPolicyPatch.x64=1
DefPolicyOffset.x64=1FE15
DefPolicyCode.x64=CDefPolicy_Query_eax_rcx
SLInitHook.x86=1
SLInitOffset.x86=5A77A
SLInitFunc.x86=New_CSLQuery_Initialize
SLInitHook.x64=1
SLInitOffset.x64=22DDC
SLInitFunc.x64=New_CSLQuery_Initialize

[10.0.18362.53-SLInit]
bInitialized.x86      =D577C
bServerSku.x86        =D5780
lMaxUserSessions.x86  =D5784
bAppServerAllowed.x86 =D578C
bRemoteConnAllowed.x86=D5790
bMultimonAllowed.x86  =D5794
ulMaxDebugSessions.x86=D5798
bFUSEnabled.x86       =D579C

bInitialized.x64      =F6A8C
bServerSku.x64        =F6A90
lMaxUserSessions.x64  =F6A94
bAppServerAllowed.x64 =F6A9C
bRemoteConnAllowed.x64=F6AA0
bMultimonAllowed.x64  =F6AA4
ulMaxDebugSessions.x64=F6AA8
bFUSEnabled.x64       =F6AAC

 

    3. 管理員啟動RDPWrap.exe

    

   ps:不配置第2步,或者版本不對的效果

   

 

  4. 執行:RDPCheck.exe 檢測是否破解成功

   

  對於已經全部綠色了,但提示“訪問拒絕”的,應該是用了當前的用戶(相同用戶)登錄了。

 

    PS:啟動RDPConf.exe 前要 重啟 “遠程桌面服務”:Remote Desktop Services 如圖

    

 

6)測試遠程登錄

    快速打開遠程登錄窗口:win+r  >>> 輸入:mstsc   

    多用戶遠程同時登錄內網機測試效果:  

    

  最後附上不同版本的rdpwrap.ini的配置信息(先看裏面有沒有合適的版本,沒有就沒必要下載了):https://gitee.com/RDNGL/rdpwrap

 

後面純屬扯淡,可以不看。

三、拓展學習

  到目前為止,多用戶同時遠程登錄內網機已完成。

       擴展其應用:內網穿透后,外網可以訪問內網,內網的服務可以被互聯網訪問,也即是可以在內網發布web服務,ftp服務等等–內網穿透的應用。

    外網可以遠程連接內網機器,多個人可以同時使用一台電腦。

    拿着一台可以聯網的筆記本便可以擁有巨大的計算資源。

       延伸為雲計算:

    趨勢:現在很多東西都開始“雲”化,這也是未來的發展方向。未來的趨勢:不需要再買固定配置的電腦,升級不僅麻煩,而且還不方便攜帶。未來只需要購買連接器設備,再開個雲計算機服務,隨時隨地升級配置,便可擁有巨大的計算資源。

         “雲”趨勢帶來的影響:硬件配置將面臨企業集中式採購,而零售數量下降。好像扯遠了……

 

 

    到目前為止全部講完了,歡迎來評論區打唾沫戰。

 

學習會讓人視野開闊,站在頂端才能仰望未來。

轉載請指明出處:https://www.cnblogs.com/dennyLee2025/p/13168408.html

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

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

南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

【Spring】AOP的代理默認是Jdk還是Cglib?,【DP-動態代理】JDK&Cglib

菜瓜:你覺得AOP是啥

水稻:我覺得吧,AOP是對OOP的補充。通常情況下,OOP代碼專註功能的實現,所謂面向切面編程,大多數時候是對某一類對象的方法或者功能進行增強或者抽象

菜瓜:我看你這個理解就挺抽象的

水稻:舉個栗子!我要在滿足開閉原則的基礎下對已有功能進行擴展

  • 我現在想對很多個功能增加日誌功能,但是代碼已經打好包了,不想改。又或者有時候方法調用很慢,想定位問題
  • low一點的方法就是每個方法調用之前記錄調用開始,之後記錄調用結束

菜瓜:你說的這個low一點的方法怎麼好像是在說我???

水稻:建議看一下動態代理設計模式【DP-動態代理】JDK&Cglib,我當然知道你不會看,所以我還準備了自定義註解的栗子

  • package com.hb.merchant.config.aop;
    
    import org.springframework.context.annotation.Configuration;
    import org.springframework.context.annotation.EnableAspectJAutoProxy;
    
    /**
     * @author QuCheng on 2020/6/23.
     */
    @Configuration
    @EnableAspectJAutoProxy
    public class AopConfig {
    }
    
    package com.hb.merchant.config.aop;
    
    import java.lang.annotation.ElementType;
    import java.lang.annotation.Retention;
    import java.lang.annotation.RetentionPolicy;
    import java.lang.annotation.Target;
    
    /**
     * @author QuCheng on 2020/6/23.
     */
    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    public @interface OperatorLog {
    }
    
    
    package com.hb.merchant.config.aop;
    
    import lombok.extern.slf4j.Slf4j;
    import org.aspectj.lang.ProceedingJoinPoint;
    import org.aspectj.lang.annotation.Around;
    import org.aspectj.lang.annotation.Aspect;
    import org.aspectj.lang.reflect.MethodSignature;
    import org.springframework.stereotype.Component;
    
    /**
     *
     * @author QuCheng on 2020/6/23.
     */
    @Aspect
    @Component
    @Slf4j
    public class OperatorAspect {
    
        @Around("@annotation(OperatorLog)")
        public Object around(ProceedingJoinPoint joinPoint) throws Throwable {
            //獲取要執行的方法
            MethodSignature methodSignature = (MethodSignature) joinPoint.getSignature();
            //記錄方法執行前日誌
            log.info("startLog: {} 開始了。。。" , methodSignature.getName());
            //獲取方法信息
            String[] argNames = methodSignature.getParameterNames();
            // 參數值:
            final Object[] argValues = joinPoint.getArgs();
            StringBuilder sb = new StringBuilder();
            for (int i = 0; i < argNames.length; i++) {
                String value = argValues[i] == null ? "null" : argValues[i].toString();
                sb.append(argNames[i]).append("=").append(value).append(",");
            }
            String paramStr = sb.length() > 0 ? sb.toString().substring(0, sb.length() - 1) + "]" : "";
            log.info("參數信息為:[{}", paramStr);
    
            //執行方法
            Object result;
            try {
                result = joinPoint.proceed();
            } catch (Exception e) {
                log.error("errorLog", e);
                return null;
            }
    
            //記錄方法執行後日志
            log.info("endLog: {} 結束了。。。" , methodSignature.getName());
            return result;
        }
    
    }
    
    
    
    package com.hb.merchant.controller.icbc.item.oc;
    
    import com.hb.merchant.config.aop.OperatorLog;
    import lombok.extern.slf4j.Slf4j;
    import org.springframework.util.Assert;
    import org.springframework.web.bind.annotation.GetMapping;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RestController;
    
    /**
     * @author QuCheng on 2020-06-23.
     */
    @RestController
    @RequestMapping("/item")
    @Slf4j
    public class ItemOcController {
    
        @OperatorLog
        @GetMapping("/delete")
        public String delete(Long itemId) {
            Assert.notNull(itemId,"itemId不能為空");
            return "delete finished ...";
        }
    }

    // 後台打印
    startLog: delete 開始了。。。
    參數信息為:[itemId=1]
    endLog: delete 結束了。。。

菜瓜:這個自定義註解又是怎麼實現的呢?

水稻:不愧是你,沒有源碼看來是滿足不了你的好奇心了!!不知道你是否還記得我們之前有聊到過bean創建完畢後會調用一些PostProcessor對其進一步操作

菜瓜:有印象,@PostConstruct註解就是InitDestroyAnnotationBeanPostProcessor在這裏調用的,還自定義過BeanPostProcessorT對象打印輸出過bean信息

水稻:你猜Spring是怎麼操作的

菜瓜:let me try try。結合剛剛的栗子和提示,大膽猜測應該是用PostProcessor在bean創建完成之後生成代理對象。實際調用代理的invoke方法實現對被代理bean的增強

水稻:思路正確。看脈絡

  • 入口在AbstractAdvisorAutoProxyCreator#initializeBean
  • protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
            。。。
                // BeanNameAware BeanFactoryAware ...
                invokeAwareMethods(beanName, bean);
        。。。    
                // BeanPostProcessorBefore  @PostConstruct
                wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
        。。。
                // initMethod InitializingBean接口
                invokeInitMethods(beanName, wrappedBean, mbd);
                。。。
            if (mbd == null || !mbd.isSynthetic()) {
                // aop
                wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
            }
            return wrappedBean;
        }
  • 從aop入口跟下去
  • protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
            。。。
            // 收集切面信息匹配被代理對象
            Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
            if (specificInterceptors != DO_NOT_PROXY) {
                this.advisedBeans.put(cacheKey, Boolean.TRUE);
          // 如果符合切面 創建代理,被代理對象被代理引用
                Object proxy = createProxy(
                        bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
                this.proxyTypes.put(cacheKey, proxy.getClass());
                return proxy;
            }
    
            this.advisedBeans.put(cacheKey, Boolean.FALSE);
            return bean;
        }
  • 跟createProxy方法 -> DefaultAopProxyFactory#createAopProxy
  • @Override
    public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException {
       if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) {
          Class<?> targetClass = config.getTargetClass();
          if (targetClass == null) {
             throw new AopConfigException("TargetSource cannot determine target class: " +
                   "Either an interface or a target is required for proxy creation.");
          }
          if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) {
            // jdk動態代理類
             return new JdkDynamicAopProxy(config);
          }
          // cglib
          return new ObjenesisCglibAopProxy(config);
       }
       else {
          return new JdkDynamicAopProxy(config);
       }
    }
  • 此處省略了切面類搜集和匹配的過程。可以簡單理解成搜集到所有的切面類信息獲取pointcut的目錄或者註解信息,匹配當前bean是否屬於pointcut目標範圍
  • 另外我們可以看到最後返回的bean已經不是原始bean了,而是代理對象。也就是說getBean(“xxx”)返回的對象實際是代理對象,被代理對象被其成員變量直接引用

菜瓜:然後代理類中都有invoke方法,那些advice(@Around,@Before…)在invoke中找到適當時機調用對吧

水稻:是的,這裏我想結合@Transactional註解會更容易理解,你肯定用過這個註解吧,它其實。。。

菜瓜:停。。。今天獲取的知識量已經夠了,我下去自己斷點走一趟再熟悉熟悉。下次請結合Transactional註解再敲打我吧

水稻:也好,我下去再給你準備幾個栗子

 

總結:

  • AOP提供了在不侵入代碼的前提下動態增強目標對象的途徑,讓OOP更加專註於實現自己的邏輯
  • 而Spring的實現還是老套路,利用PostProcessor在類初始化完成之後替需要的bean創建代理對象
  • 這裏還有一些細節沒有照顧到,譬如說AOP解析類是什麼時候註冊到IOC容器的(偷偷告訴你從@EnableAspectJAutoProxy註解下手)

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

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

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

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

※別再煩惱如何寫文案,掌握八大原則!

現代化編程模式(1)-快

感謝大家購買我的書

首先十分感謝大家購買我的書,在Tommy和Julisa購買我的書的時候,我承諾會開Sharing給大家。我開Sharing的目標就是讓像Tommy和Julisa這樣的基礎比較低的人都能夠學會編程。所以我就以Tommy和Julisa為目標制定sharing課程,不再按照書籍章節順序一章一章的講。

現代化編程模式核心 – 快

我這本書最值得學習的地方不是.NET,所以這節sharing我故意不用.NET來演示,而是採用JavaScript來演示。

我這本書最值得學習的地方也不是併發。

我這本書最值得學習的地方是“現代化的編程模式”。也就是如下標黃處

 

 

 

現代化編程模式核心只有一個字,就是 – 快!

為了显示出快,我故意挑選了最慢的JavaScript來做這次sharing的演示語言!

現代化編程模式適用於所有現代化的編程語言,包括.NET/(C#和F#),Java,Python,JavaScript,Scala,Clojure,Swift。所以無論是我書中的C#和F#,還是我這次sharing用的JavaScript,都是通用的。最典型的就是本書第6章所講的Rx,它就有多個編程語言的版本:Java,JavaScript,.NET,Scala,Clojure,Swift。以下截圖取自Rx的官網 http://reactivex.io/

 

 

 

快主要來自兩個方面:

  • 程序運行速度快。
  • 編程速度快。

程序運行速度快

從大家的反饋來看,大家不太關注這點,所以我這次sharing先不講,以後再講。

編程速度快

所有技術的進步趨勢都是越來越容易,門檻越來越低,編程也同樣如此!

現在我回首十九年前(2001年)我用C語言寫出第一個程序的時候,當時的編程門檻是相當的高。當時的Turbo C 2.0還是跑在Dos上的,與今天相比真是天壤之別。編程門檻越來越低,編程工具環境越來越完善。這些基礎設施的完善決定了我們編程速度會越來越快。所以大家不需要再對編程帶有恐懼感,覺得編程難!現在編程的難度已經是你讀書時代的幾十分之一了!如果你掌握的是現代化的編程模式而不再是傳統古老的編程模式的話。

在這次sharing我只講大家最容易理解的幾點:

  • 調試診斷快
  • 不用動腦跟着感覺走導致行動快
  • 不用等待他人協作導致自身行動快

調試診斷快

在傳統的編程模式中,我們是這樣編程的:

  1. 啪啪啪敲一堆鍵盤之後,程序寫完了。
  2. 跑起來試一下,oh! No! 出錯了!(耗時幾分到十幾分鐘)
  3. 這時候就加斷點調試,先進一點的就不加斷點,而是看log來診斷。(至少耗時一分鐘起)

大家可以看到,第二步和第三步耗時都是以分鐘為單位的。如果unlucky,第三步可能要按小時甚至天為單位。為了加深大家的印象,sharing的時候我會視時間多少而現場演示一遍這個痛苦的傳統編程模式。

但是現代化的編程模式是以秒為單位的,比以分為單位的傳統編程模式快了一個數量級!!!

Sharing的時候我以JavaScript為編程語言,Visual Studio Code為編程工具,框架選karma + jasmine + AngularJS(我故意沒選最近的Angular而是選AngularJS,也是為了證明現代化編程模式是通用的)來演示現代化編程模式是如何以秒為單位進行調試診斷的。

現代化編程模式以秒為單位進行調試診斷的要點在於:

  1. 每Save一次就會把所有BDD Test cases在一兩秒內跑完!
  2. 基於上一點,也就是說,與傳統的編程模式相比,我馬上就能知道結果,而不是要等幾分鐘。
  3. 基於上一點,就可以每改一點代碼,就馬上Save,同時就馬上知道結果。如果此時發現BDD Test Case變紅了,馬上就知道剛才改的哪一處代碼有錯誤。馬上就能知道原因,馬上就能夠Fix!這裏的每改一點代碼可以理解成:每改一行代碼,每改一個字符,等等。
  4. 因為每次修改代碼的粒度是如此之小,小到每一行和每一個字符,可謂:一步一個腳印。並且每次改動都能保證程序是能BDD Test Case跑通過的,自然也就不需要加斷點調試和看log來診斷了。
  5. 然而人總是會犯錯的,程序出錯時,現代化編程模式不需要通過加斷點調試和看log診斷這種這麼古老的方式,而是通過不斷的加BDD Test Case和縮小Scope來定位問題發生的地方以及去解決。

這部分實操內容也是這次Sharing的大頭。

不用動腦跟着感覺走導致行動快

傳統的編程模式需要程序員去動腦,去思考程序代碼的流程,所以需要寫if/else/switch/for/foreach等語句。然而動腦是很容易累的,同時又是很耗時間的,所以傳統的編程模式自然是快不起來的!

“動腦是不可能動腦的啦,做生意又不會,只能跟着感覺走寫寫代碼才能生活這樣子”

竊-格瓦拉

現代化編程模式改變了思路,不再去思考程序代碼的流程:

 

傳統的編程模式

現代化編程模式

程序員所要做的

需要動腦思考如何做,需要明確的指出每一步該怎麼做。

只需要告訴計算機你的目標即可!

相關編程語句和庫

if/else/switch/for/foreach

LINQ,Reactive Extensions, Promises (不應該再出現if/else/switch/for/foreach)

專業術語

命令式編程

聲明式編程

 

 

 

補充多一句:聲明式編程語言通常用作解決人工智能和約束滿足問題。哈哈,看到這裏大家都懂的啦。

從上面的表格對比中可以看出,“只需要告訴計算機你的目標”的現代化編程模式明顯就比“還需要明確的指出每一步該怎麼做。”的傳統編程模式節省腦子很多!!!

大家可以看看 https://baike.baidu.com/item/%E5%A3%B0%E6%98%8E%E5%BC%8F%E7%BC%96%E7%A8%8B/9939512 來預習一下

 

 

 

不用等待他人協作導致自身行動快

自從進入移動互聯網時代之後,因為客戶端設備的多樣化,前後端分離已經成了大趨勢。同時也帶來了一個大問題:前後端程序員協作的問題!

接着前面“調試診斷快”一節中所share的內容,傳統的編程模式對前後端程序員聯調的依賴性比較高。而現代化編程模式因為可以通過mock的方式來模擬絕大部分後端的響應,前端程序員不再需要等待後端程序員的工作了,從而節約了這部分時間,導致自身在項目進度中更快更有保障。

在這次sharing中我所使用的Karma(BDD框架)和Jasmine(包含了httpbackend mock庫的unit testing框架)在其他編程語言中都有對應的框架和庫,再次體現了現代化編程模式是在各種編程語言中是通用的!!!

總結和動手口訣

在這次sharing之前,我請了兩位老夥計参觀了一下,都得到了好評,希望參加的有經驗的程序員也同樣會一聲驚嘆!

當然,非程序員還是不可能只通過這一次sharing就馬上學會編程的,所以對於你們來說,這次sharing的目的應該是:你能夠識別和分辨出哪些才是編程里正確的道路,從而找到先進的編程資料和避免誤讀落後的編程資料。關於這點,我總結了口訣如下:

  1. 快是王道!
    凡是要一分鐘以上才能看到編程運行結果的都是落後的編程模式,現代化模式是一兩秒就能看到運行結果的。凡是要通過debug和看log這麼耗時的行為,我們都要思考是否通過BDD來減少時間。
  2. 節省腦力是王道!
    現代化編程模式已經可以實現了只需要告訴計算機你的目標即可!如果還需要費腦子去想if/else/switch/for/foreach。那你就落後了。
  3. 能夠獨立完成任務,不依賴別人是王道!
    Mock+BDD已經可以讓你不需要過多等待和依賴其他程序員的工作了。

大家下周sharing見!

風險提示:

我的blog文章和我所翻譯和所寫的書籍不一樣:

    • 沒有像書籍一樣經過三審三校。所以不像書籍一樣嚴謹和全面。
    • 都有當時特定的閱讀對象,然而每篇blog的閱讀對象都不一樣,這點和書籍十分不一樣。所以如果你讀起來覺得怪怪的,那很有可能是你與該篇blog閱讀對象差異很大。
    • 所有文章全部不構成任何投資建議。如因採納這些文章而進行投資所造成的虧損,我不負任何責任。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

南投搬家公司費用需注意的眉眉角角,別等搬了再說!

新北清潔公司,居家、辦公、裝潢細清專業服務

※教你寫出一流的銷售文案?