騰訊出資！中國版特斯拉 NextEV 先瞄準中國市場

2020-05-262020-05-26 admin

騰訊和高瓴資本在內等多家中國網路巨頭和金融投資機構共同投資的新能源汽車廠商 NextEV，將成為特斯拉（Tesla）的競爭對手。據路透報導，NextEV 發言人劉吉利表示，已聘請福特前高管 Martin Leach 打造一家全球性汽車廠商，他們還招聘了有在特斯拉、寶馬（BMW）、大眾（VW）和其他主要汽車廠商工作經驗的專家。他強調，NextEV 將先瞄準中國市場，然後走向世界。 NextEV 投資方包括數家非汽車廠商的中國科技公司，且其開發電動車的努力得到中國政府的支持，中國政府最近修改相關法規，允許非汽車廠商投資電動汽車產業。目前已宣布或在考慮投資電動汽車產業的中國科技公司包括阿里巴巴、小米和樂視。劉吉利表示，NextEV 推出的第一款產品將是一款電動超級跑車，預計該車表現將超過世界上所有採用內燃機的跑車。NextEV 並將於明年推出賽車車型，功率超過1000馬力，加速到時速 100 公里僅需 3 秒。之後 NextEV 還會推出一系列高性能車型。

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

【其他文章推薦】

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

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

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

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

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

台廠昶洧研發系列電動車 Thunder Power 將於 2017 年歐洲上市

2020-05-262020-05-26 admin

昶洧自有品牌 Thunder Power 電動車系列，於「2015 法蘭克福國際車展(9 月 17 日至 27 日)」中進行首秀。昶洧表示，Thunder Power 電動車系列量產車預計將於 2017 年在歐洲上市，2018 年在中國大陸上市，之後更將進一步拓展美國市場。 Thunder Power 主要生產廠將設在大陸浙江省紹興市，而歐洲的生產基地，待確定後也將公佈。公司指出，目前所有研發活動都將由昶洧設在米蘭附近的歐洲總部開展並管理，而設在中國大陸和美國的研發機構將負責提供額外支持。昶洧指出，Thunder Power 作為一款後驅電動轎車，擁有令人興奮的駕控性能，和令同儕豔羨的強大續航能力，該系列車型輸出功率有 230 千瓦或 320 千瓦 2 款動力選擇，充滿電後可行駛超過 650 公里，經過 30 分鐘短暫充電，可再行駛 300 多公里，強大的續航能力足以傲視同級；320 千瓦功率車型在 5 秒內便可完成 0-100 公里加速，最高時速可達 250 公里。昶洧董事長沈瑋表示，公司歷經 5 年多研發，於本屆法蘭克福國際車展上展出 Thunder Power 豪華電動車系列，選擇在此舉行全球首秀，希望吸引全球媒體、投資人和消費者的目光；相信電動車成為主流並取代內燃發動機汽車，不再是不可能的事，而只是時間問題。

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

【其他文章推薦】

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

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

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

※南投搬家前需注意的眉眉角角，別等搬了再說!

China .NET Conf 2019-.NET技術架構下的混沌工程實踐

2020-05-252020-05-25 admin

這個月的8號、9號，個人很榮幸參加了China.NET Conf 2019 , 中國.NET開發者峰會，同時分享了技術專題《.NET技術架構下的混沌工程實踐》，給廣大的.NET開發小夥伴介紹混沌工程和高可用性改造實踐。會後大傢伙聚餐的時候，陳計節老師建議大家將各自的議題分享到社區，分享給大家。因此，今天和大家分享我的技術專題《.NET技術架構下的混沌工程實踐》。

先放幾張大會照片：

整個專題主要分為四個部分：

.NET分佈式、微服務架構下的高可用性挑戰
混沌工程簡介
.NET混沌工程的實踐和成果分享
展望和規劃

一、.NET分佈式、微服務架構下的高可用性挑戰

目前，我們特來電的技術架構是分佈式、微服務化的，線上超過1000台Server，高可用保障壓力很大：

系統7*24小時運行，不允許宕機，一旦宕機出問題，直接影響全國人民出行；
系統SLA要求99.95% ，全年可宕機時間只有4.38小時；
服務調用鏈路越來越長，依賴越來越複雜，某個環節出問題，都有肯能導致服務雪崩、大規模宕機；
線上遭遇：網絡抖動、內存泄露、線程阻塞、CPU被打爆、數據庫被打爆、中間件宕機等棘手問題；
每天上百次發布更新，系統高可用性保障壓力非常大；

一張全鏈路監控圖可以反映我們系統的複雜：

例如主機CPU被打爆的問題，線上經常會遇到：

經歷了線上各種高可用性問題后，我們做了很多反思和總結：

系統在實現了分佈式、微服務化之後，我們到底有多少把握來保證系統的正常運行？

如果出現問題，整個分佈式系統會變得非常“混亂”，甚至會引發系統的大規模宕機。

因此，我們有必要在線上事故出現之前，提前識別出系統有哪些弱點和問題，統一管控系統的固有混沌。

這套管控系統固有混沌的方法和體系，就是我們今天要介紹的主角：混沌工程。

二、混沌工程簡介

1. 什麼是混沌工程？

通過受控的實驗，掌握系統運行行為的過程，稱為混沌工程。

混沌工程的典型實踐：Chaos Monkey
一隻搗亂的猴子，在你的系統裏面上蹦下竄，不停搗亂，直到搞掛你的系統。

2. 為什麼需要混沌工程？

混沌工程可以提升整個系統的彈性。
通過混沌實驗，可以發現系統脆弱的一面，主動發現這些問題，並解決這些問題。

3. 混沌工程怎麼做？

混沌工程的一般實施步驟：

1 選擇系統正常運行狀態下的可度量指標，作為基準的“穩定狀態” 2 混沌實驗分為實驗組和對照組，都能保持系統的“穩定狀態” 3 對實驗組注入混沌事件，如服務不可用、中間件宕機等混沌事件 4 比較實驗組和對照組“穩定狀態”的差異

如果混沌實驗前後系統的“穩定狀態”一致，則可以認為系統應對這種混沌事件是彈性的、高可用的。
相反的，如果打破了系統的穩定狀態，我們就找到了一個系統弱點，然後盡可能地解決它，提升系統的高可用性。

4. 實施混沌工程的推薦原則

明確系統穩定運行的狀態（指標）
混沌事件必須是現實世界可能發生的（合理的）
在生產環境進行混沌實驗：生產環境可以真實地反映系統的穩定性
持續集成：線上應用每天都在更新，通過持續集成的方式可以不斷髮現問題、解決問題。
最小化影響範圍：線上進行混沌實驗，必須可控，必須確定混沌實驗的最小化影響範圍。

這裏大家會問：在生產環境上搞混沌實驗，能行嗎？

5. 現實中的混沌工程

生產環境必須以穩定為前提，因此推薦O2O模式的混沌實驗：即線下演練、線上驗證
在系統未經過大規模高可用性改造之前，建議首先進行全面的線下演練：

那麼, .NET技術架構下的混沌工程怎麼做？

三、.NET混沌工程的實踐和成果分享

我們線上系統主要用到了以下.NET技術棧和開源技術：

ASP.NET MVC
基於ASP.NET Core的Web運行框架-WRF
基於ASP.NET Web API的分佈式服務網關-SG
基於.NET RPC通訊技術的分佈式微服務平台-HSF
基於RabbitMQ和Kafka的消息應用中心-MAC
iBatis.NET & Entity Framework
RabbitMQ & RabbitMQ Client for .NET
Kafka & Confluent.Kafka
Redis
Nginx
…

在上述.NET 技術架構下，我們梳理了大量的混沌工程事件：

通過大量的混沌實驗，我們逐步建立了提升系統高可用性的方法論和體系：

.NET技術架構下的高可用性改進-依賴治理、容錯降級

業務場景：
隨着業務複雜度的上升，服務調用鏈路越來越長，鏈路上存在大量不可控的因素：

- 網絡抖動，導致服務異常
- Redis、MQ、DB等中間件不可用，導致服務超時、異常
- 依賴的服務不可用，直接影響服務調用方

如何應對：識彆強弱依賴，對弱依賴進行降級，對強依賴有限降級

- “用戶有感知” 是強依賴
- “用戶無感知” 是弱依賴
- 故障發生時，核心業務有損失的是強依賴，無損失的是弱依賴

.NET技術架構下的高可用性改進-解耦/隔離

業務場景：
核心業務的調用鏈路很長，整個鏈路上包含主流程和輔流程
輔流程的重要性低，不能因為輔流程的不可用，影響了主流程。

如何應對：

.NET技術架構下的高可用性改進-超時治理

業務場景：
對於服務超時，長時間等待會影響用戶體驗，併發大時還可能造成線程池被打爆。
同時可能產生服務級聯反應，導致大範圍服務雪崩。

應對方案：
超時時間設置：服務剛上線時，可以根據壓測情況預估一個值；
服務上線后再根據實際監控進行修改，比如設置99%的請求響應時間為超時時間。
超時后的處理策略：
如果不是核心服務，可直接超時返回失敗。
如果是核心服務，可以設置相應的重試次數.

示例：
配置服務超時時間
設置Http請求超時時間
設置數據庫連接超時、SQL執行超時
代碼控制超時時間（例如：Polly的Timeout策略）

.NET技術架構下的高可用性改進-重試補償

業務場景：
實際線上應用中，假如遇到網絡抖動、發布重啟、數據庫阻塞超時等情況，都有可能引起服務調用失敗。

應對方案：
通過失敗重試、異常后的補償，盡可能地保證業務可用。
重試情況下：業務要保證冪等性、保證最終一致性。

示例：
服務失敗重試策略
消息發送、消費失敗重試、補償
代碼層面失敗重試補償（例如：Polly的Retry策略）

高可用改進還有很多技巧，這裏不一一詳細給大家贅述了。

通過對系統進行全面的高可用性改進，提升了我們對線上系統的信心！

四、展望和規劃

2019年，我們啟動了混沌工程實踐，逐步建立了混沌工程的自有方法論和體系，通過近一年的混沌工程實踐，混沌工程文化逐漸被開發團隊所認可。目前，混沌工程已經逐步過渡到線上生產環境進行（這來自於足夠的信心和把握）。但這隻是一個起步，未來：

正式的混沌工程團隊：通過多團隊配合、保障資源的持續投入
覆蓋所有的關鍵核心應用：讓混沌工程深入到每個產品
堅持O2O混沌工程實踐：線下演練、線上驗證，更可控
混沌事件注入工具：ChaosBlade for .NET，工具讓混沌工程更高效
持續的混沌實驗：持續進行、持續改進

目標：通過混沌工程揭示問題、解決問題、形成閉環，不斷提升系統高可用性。

以上是本次China.NET Conf 2019的技術專題，分享給大家。

周國慶

2019/11/15

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

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

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

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

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

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

如何使用24行JavaScript代碼實現Redux

2020-05-252020-05-25 admin

作者：Yazeed Bzadough
譯者：小維FE
原文：freecodecamp

為了保證文章的可讀性，本文採用意譯而非直譯。

90%的規約，10%的庫。
Redux是迄今為止創建的最重要的JavaScript庫之一，靈感來源於以前的藝術比如和，Redux通過引入一個包含三個簡單要點的可伸縮體繫結構，使得JavaScript函數式編程成為可能。如果你是初次接觸Redux，可以考慮先閱讀。

1. Redux大多是規約

考慮如下這個使用了Redux架構的簡單的計數器應用。如果你想跳過的話可以直接查看。

1.1 State存儲在一棵樹中

該應用程序的狀態看起來如下：

const initialState = { count: 0 };

1.2 Action聲明狀態更改

根據Redux規約，我們不直接修改(突變)狀態。

// 在Redux應用中不要做如下操作
state.count = 1;

相反，我們創建在應用中用戶可能用到的所有行為。

const actions = {
  increment: { type: 'INCREMENT' },
  decrement: { type: 'DECREMENT' }
};

1.3 Reducer解釋行為並更新狀態

在最後一個架構部分我們叫做Reduer，其作為一個純函數，它基於以前的狀態和行為返回狀態的新副本。

如果increment被觸發，則增加state.count
如果decrement被觸發，則減少state.count

const countReducer = (state = initialState, action) => {
  switch (action.type) {
    case actions.increment.type:
      return {
        count: state.count + 1
      };

    case actions.decrement.type:
      return {
        count: state.count - 1
      };

    default:
      return state;
  }
};

1.4 目前為止還沒有Redux

你注意到了嗎？到目前為止我們甚至還沒有接觸到Redux庫，我們僅僅只是創建了一些對象和函數，這就是為什麼我稱其為”大多是規約”，90%的Redux應用其實並不需要Redux。

2. 開始實現Redux

要使用這種架構，我們必須要將它放入到一個store當中，我們將僅僅實現一個函數：createStore。使用方式如下：

import { createStore } from 'redux'

const store = createStore(countReducer);

store.subscribe(() => {
  console.log(store.getState());
});

store.dispatch(actions.increment);
// logs { count: 1 }

store.dispatch(actions.increment);
// logs { count: 2 }

store.dispatch(actions.decrement);
// logs { count: 1 }

下面這是我們的初始化樣板代碼，我們需要一個監聽器列表listeners和reducer提供的初始化狀態。

const createStore = (yourReducer) => {
    let listeners = [];
    let currentState = yourReducer(undefined, {});
}

無論何時某人訂閱了我們的store，那麼他將會被添加到listeners數組中。這是非常重要的，因為每次當某人在派發(dispatch)一個動作(action)的時候，所有的listeners都需要在此次事件循環中被通知到。調用yourReducer函數並傳入一個undefined和一個空對象將會返回一個initialState，這個值也就是我們在調用store.getState()時的返回值。既然說到這裏了，我們就來創建這個方法。

2.1 store.getState()

這個函數用於從store中返回最新的狀態，當用戶每次點擊一個按鈕的時候我們都需要最新的狀態來更新我們的視圖。

const createStore = (yourReducer) => {
    let listeners = [];
    let currentState = yourReducer(undefined, {});
    
    return {
        getState: () => currentState
    };
}

2.2 store.dispatch()

這個函數使用一個action作為其入參，並且將這個action和currentState反饋給yourReducer來獲取一個新的狀態，並且dispatch方法還會通知到每一個訂閱了當前store的監聽者。

const createStore = (yourReducer) => {
  let listeners = [];
  let currentState = yourReducer(undefined, {});

  return {
    getState: () => currentState,
    dispatch: (action) => {
      currentState = yourReducer(currentState, action);

      listeners.forEach((listener) => {
        listener();
      });
    }
  };
};

2.3 store.subscribe(listener)

這個方法使得你在當store接收到一個action的時候能夠被通知到，可以在這裏調用store.getState()來獲取最新的狀態並更新UI。

const createStore = (yourReducer) => {
  let listeners = [];
  let currentState = yourReducer(undefined, {});

  return {
    getState: () => currentState,
    dispatch: (action) => {
      currentState = yourReducer(currentState, action);

      listeners.forEach((listener) => {
        listener();
      });
    },
    subscribe: (newListener) => {
      listeners.push(newListener);

      const unsubscribe = () => {
        listeners = listeners.filter((l) => l !== newListener);
      };

      return unsubscribe;
    }
  };
};

同時subscribe函數返回了另一個函數unsubscribe，這個函數允許你當不再對store的更新感興趣的時候能夠取消訂閱。

3. 整理代碼

現在我們添加按鈕的邏輯，來看看最後的源代碼：

// 簡化版createStore函數
const createStore = (yourReducer) => {
  let listeners = [];
  let currentState = yourReducer(undefined, {});

  return {
    getState: () => currentState,
    dispatch: (action) => {
      currentState = yourReducer(currentState, action);

      listeners.forEach((listener) => {
        listener();
      });
    },
    subscribe: (newListener) => {
      listeners.push(newListener);

      const unsubscribe = () => {
        listeners = listeners.filter((l) => l !== newListener);
      };

      return unsubscribe;
    }
  };
};

// Redux的架構組成部分
const initialState = { count: 0 };

const actions = {
  increment: { type: 'INCREMENT' },
  decrement: { type: 'DECREMENT' }
};

const countReducer = (state = initialState, action) => {
  switch (action.type) {
    case actions.increment.type:
      return {
        count: state.count + 1
      };

    case actions.decrement.type:
      return {
        count: state.count - 1
      };

    default:
      return state;
  }
};

const store = createStore(countReducer);

// DOM元素
const incrementButton = document.querySelector('.increment');
const decrementButton = document.querySelector('.decrement');

// 給按鈕添加點擊事件
incrementButton.addEventListener('click', () => {
  store.dispatch(actions.increment);
});

decrementButton.addEventListener('click', () => {
  store.dispatch(actions.decrement);
});

// 初始化UI視圖
const counterDisplay = document.querySelector('h1');
counterDisplay.innerHTML = parseInt(initialState.count);

// 派發動作的時候跟新UI
store.subscribe(() => {
  const state = store.getState();

  counterDisplay.innerHTML = parseInt(state.count);
});

我們再次看看最後的視圖效果：

原文:

4. 交流

本篇主要簡單了解下Redux的三個架構組成部分以及如何實現一個簡化版的Redux，對Redux能有進一步的了解，希望能和大家相互討論技術，一起交流學習。

文章已同步更新至，若覺文章尚可，歡迎前往star！

你的一個點贊，值得讓我付出更多的努力！

逆境中成長，只有不斷地學習，才能成為更好的自己，與君共勉！

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

【其他文章推薦】

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

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

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

※南投搬家前需注意的眉眉角角，別等搬了再說!

Magicodes.Pay，打造開箱即用的統一支付庫，已提供ABP模塊封裝

2020-05-222020-05-22 admin

Magicodes.Pay，打造開箱即用的統一支付庫，已提供ABP模塊封裝

簡介

Magicodes.Pay，是心萊科技團隊提供的統一支付庫，相關庫均使用.NET標準庫編寫，支持.NET Framework以及.NET Core。目前已提供Abp模塊的封裝，支持開箱即用。

Nuget

新的包

已棄用的包，不再更新

主要功能

Magicodes.Pay，是心萊科技團隊提供的統一支付庫，相關庫均使用.NET標準庫編寫，支持.NET Framework以及.NET Core。目前已提供Abp模塊的封裝，支持開箱即用。目前支持以下支付方式和功能：

支付寶支付

APP支付
Wap支付

支付寶國際支付

支持分賬

微信支付

小程序支付
APP支付
訂單查詢
企業付款（提現）
退款申請
普通紅包

通聯支付

小程序支付

統一支付回調處理
支持日誌函數注入（不依賴支付庫）
支持支付配置函數注入，以便於支持自定義配置獲取邏輯，以應用於不同的場景（比如從配置文件、用戶設置獲取配置，或者多租戶支持）
針對ABP提供模塊封裝，添加模塊依賴即可立即使用。主要包括：

支付渠道註冊（IPaymentRegister）
支付回調邏輯處理（IPaymentCallbackAction）
統一支付服務實現（IToPayService）
統一支付服務封裝（見IPayAppService）
支付管理器封裝（IPaymentManager），包含：
交易日誌封裝，自動記錄客戶端信息以及自動異常處理和記錄
僅需編寫一次回調邏輯，即可支持多個支付渠道
業務參數支持更大長度（500）

開始使用

如果使用Abp相關模塊，則使用起來比較簡單，具體您可以參考相關單元測試的編寫。主要有以下步驟：

引用對應的Abp支付的Nuget包如果僅需某個支付，僅需引用該支付的包。下面以通聯支付為例，我們需要在工程中引用此包：
添加模塊依賴在對應工程的Abp的模塊（AbpModule）中，添加對“AbpAllinpayModule”的依賴，如：

 [DependsOn(typeof(AbpAllinpayModule))]

在DbContext中添加名為“TransactionLogs”的DbSet 整個支付過程中（無論是支付成功還是出現異常），均會記錄交易日誌。交易日誌會記錄交易過程中的一些信息，比如客戶端信息、交易參數、自定義參數以及異常信息。因此我們需要針對EF添加對TransactionLog的支持。需要在DbContext中添加的完整代碼如下所示：

public DbSet<TransactionLog> TransactionLogs { get; set; }

註冊回調邏輯我們需要實現“IPaymentCallbackAction”接口來編寫自定義的回調邏輯。如以下示例所示：

public class TestPaymentCallbackAction : IPaymentCallbackAction
    {
        /// <summary>
        /// 業務Key
        /// </summary>
        public string Key { get; set; } = "繳費支付";

        /// <summary>
        /// 執行回調
        /// </summary>
        /// <returns></returns>
        public async Task Process(IUnitOfWorkManager unitOfWork, TransactionLog transactionLog)
        {
            var data = transactionLog.CustomData.FromJsonString<JObject>();
            //業務處理

            await Task.FromResult(0);
        }
    }

注意Key不要重複。

向容器中註冊回調邏輯

我們可以將回調邏輯寫在一個公共的程序集，然後使用以下代碼進行註冊：

 IocManager.IocContainer.Register(
                //註冊自定義支付回調邏輯
                Classes.FromAssembly(typeof(ApplicationCoreModule).GetAssembly())
                    .BasedOn<IPaymentCallbackAction>()
                    .LifestyleTransient()
                    .Configure(component => component.Named(component.Implementation.FullName))
                    .WithServiceFromInterface()
            );

除了上面的方式，我們還可以通過注入IPaymentManager對象，通過其RegisterCallbackAction方法來註冊自定義的回調邏輯。

發起支付

通過容器獲得IPayAppService，然後調用Pay方法即可。也可以自行封裝：

public async Task<object> Payment(PaymentInput input)
        {
            return await _payAppService.Pay(new PayInputBase()
            {
                Body = $"{input.Name} {input.ChargeProjectName}",
                CustomData = input.ToJsonString(),
                Key = "繳費支付",
                OpenId = input.OpenId,
                Subject = input.ChargeProjectName,
                TotalAmount = input.Amount,
                PayChannel = input.PayChannel
            });
        }

通過IPayAppService統一支付有如下好處：

統一支付（無論支付寶還是微信各種端的支付，均可統一）
自動記錄交易日誌以及進行相關邏輯處理
自定義數據依賴交易日誌進行存儲，而不依賴支付渠道，因此支持無業務參數的支付渠道，也支持存儲更多自定義數據

非ABP集成

請參考Abp相關模塊的封裝或者歷史代碼。

官方訂閱號

關注“麥扣聊技術”訂閱號免費獲取：

最新文章、教程、文檔
視頻教程
基礎版免費授權
模板
解決方案
編程心得和理念

官方博客/文檔站

其他開源庫地址

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

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

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

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

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

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

敏捷開發：我在路上

2020-05-222020-05-22 admin

略有耳聞

行業變化真的很快~思想更新迭代更是應接不暇。

我在最早最早聽到敏捷開發的時候是2014年，入行剛剛兩年。

猶記得當初領導引出這個話題，大家討論開來。

“咱們敏捷不起來，那是外國玩的東西”

“敏捷就是快，極限編程，到時候代碼都是坑。還得重構”

其實很多對話已經很模糊了。但是整體的氛圍就是，想玩會把自己玩死。

當時作為一顆小白菜的我~，完全聽不懂他們在講什麼。只能從字面意義去暢想。

敏捷–就是快速的意思唄，快就對了。

極限–是不是就是給你個需求你能超出極限干出來。

這太恐怖了。後面這個話題慢慢就不知不覺中煙消雲散

痛苦

對敏捷的認識，我的思想依舊停留在之前的認知。一直沒有人討論，也沒有過自己主動補充。

主要原因，周圍的人習慣了這種跨度長，按部就班的迭代方式。

即便是有人提出過異議，依舊還是寡不敵眾，重回其道。

2017年11月到 2019年元旦，這是我感觸頗深的一段時間。

因為分組原因，起初有一個很不起眼的系統放在了我們組，然後這個系統從無到有，我們進行快速開發上線。直到我一個人維護這個系統兩年。

後面因為我還有另外一個重要的工作，使得這兩個工作項，在衝突中迭代，在痛苦中來回切換。

其中的痛苦對於沒有管理經驗的我來說真的是煉獄。

我向管理層提出了我的想法，是不是可以改變一下這種節奏？

通過深思熟慮我從.NET組轉到了php組（可以理解為也是技術棧的完全切換），就是我們說的轉語言。

但是轉過的我，依舊痛苦。需求不斷，我依舊使用C#迭代着這個內部系統。

10月份接到一個高層領導們提出很多需求，準備一個大版本迭代。必須在元旦前上線。

首先：

人不夠 — 找外包和我一起來做

時間長 — 砍掉估時的一半，加班做

資金 — 外包2人，算是增加了預算

結果可想而知：

好在上線了（元旦加了幾天班，一個外包沒來，另一個最後一天因為胃不舒服回家了）

我現在想起元旦自己一個人在一個項目群里回復着4~5個測試（系統測試、性能測試），

一個人改着bug，改完bug列表，刷新后馬上又多了幾個bug的崩潰。

php組的領導也確實幫不上忙，默默陪着我，協調資源和處理其他問題。多虧領導的陪伴，要不我真的能放棄。

這個時候，我的小孩出生也有4個多月了。

那一年的8月，也就是2018年8月，我從老東家離職。

我給我的理由是：離家遠，想早點回家看孩子。

這個理由真的很牽強。我真的感覺倦了，感覺無休止地看不到頭，感覺自己更加迷茫。

反思

我從上一家公司離職后，到現在一年多。我才慢慢體會到我所說的痛苦都是有原因的，而且完全可以避免和克服。

入職新公司，參与了一個項目，並嘗試着管理一個項目。公司有整個項目周期的管理流程。

我從流程中學習如何管理項目。經過一年多的學習和轉變，我學習着分析當初我的痛苦。

沒有項目管理經驗的我

因為我最熟悉代碼和業務，所以組織外包分配任務。但是沒有經驗和想法的我把這個項目管理得一團糟。

我應該可以更加清晰地分配任務，使得任務相對獨立。

我也可以更加詳細地拆分任務，因為我對邏輯非常熟悉，所以可以將複雜操作拆得更加詳細

我在項目中開發，無法脫身，完全可以從上層角度來提前協調資源。

我當時的技術面比較窄，無法從更高的技術角度看代項目。

我知道當時的外包很貴，領導可能出於預算，分析了任務量，確認了2個外包。

整個開發沒有層次，測試都在最後一擁而上，我們不得不在群里說著這個功能的實現細節。然後測試再去測試。

對這個項目預估不足

沒有預估到這個內部系統如此複雜的業務纏繞

沒有預估到這個系統整個迭代如此混亂，沒有節奏，沒有章法。

心態

一開始我就輸了，輸在了心態

我總是想着2年的系統沒有文檔，重構是完不成的。

我總是想着完不成也有理由，因為A,B，C

遇到困難或在極其艱難的時候，沒有正面困難的勇氣，我選擇了抱怨和唉聲嘆氣，我選擇了消極應戰。對，我的士氣確實沒有了。

如果

如果，再有如果，我使用一些項目管理的方法和在實踐中總結的方法，再次迭代這個項目，那結果會是怎樣？

如果我再負責一點，把模塊拆開，任務分細，即便是外包來做，也不會被項目嚇到？

如果我在開始前，做了詳細的項目迭代規劃，可以先交付什麼，后交付什麼，前後沒有大的關聯。測試資源可以儘早介入。

如果我在開發前，做好風險準備以及應對方案，是不是開發中有時候就不會那麼被動？

我總結就是：層次、心性、管理

為什麼是這三個詞，這也是我覺得我從一個普通程序員轉變成初級管理的一個總結。

層次：我當初壓根就沒有轉管理的這根線，所以分析問題都是從自身角度，層次可想而知。

心性：做好了轉管理的準備，心性也要做好準備，遇到棘手的問題，客戶的催促。我必須放下抱怨、冷靜分析選擇最合適的解決方案。

管理：我思想和心裏都做好了準備，我確實需要一些指導，比如老領導的幫帶，一些書籍的閱讀。從認知上再次提升

       剩下的就是在實踐中不斷打磨自己的認知和理解，總結后再嘗試。

重新定義自己

2018年8月中旬來到現在的公司，這裏我接觸了一些項目管理的流程。

我嘗試管理項目，我嘗試總結問題，我嘗試全局分析。

這一年我犯了很多錯，回過頭髮現當初的自己是多麼幼稚不堪。

還好，我在同事和領導身上，慢慢學習他們的優點和經驗。

如何管理項目、把控流程、協調資源、拆分任務

如何和上級溝通

如何和同事更好協作

如何把自己身上的任務合理分下去，同時關注帶的人的成長

比如購銷合同一個緊急項目，如何跨部門協調，如何在緊急情況下做出合適的方案並協調資源。

... ...

重新認識敏捷

2019年3月，我們部門來了一個新同事，了解到他之前公司一直是敏捷開發。

我們時不時一起討論敏捷開發等相關問題。

“我們的任務是儘早持續交付有價值的軟件，並讓用戶滿意”

這一敏捷宣言，細細品味，確實蘊藏了巨大的能量。

圍繞着這一句話，我們可以想象到很多的方面進行改進，以接近這一宣言。

用戶為中心

價值導向

持續集成

優先級

自主管理

協作溝通

以人為本

等......

我們所使用的這些方法和策略，就是在慢慢打造更高效的團隊。發揮價值。

發揮價值，然後慢慢改造流程，發揮更大的價值。

就是在一個循環往複中，螺旋上升。

起初會有不適應，因為人都是有惰性的，組織和規範都是有平衡的。

敏捷的這些思想，無時無刻地衝擊着這些人性、組織以及規範。

當在堅持實行的過程中，信任他人，成就他人，這樣慢慢激發人性的能量。團隊收穫的是能量，個人收穫的是成長。

堅持實行敏捷，是一項艱巨的任務。這需要團隊不斷磨合，不斷找到合適的相處方式，找到每個人的能力成長點，並激發它。

敏捷最終落腳的地方是人，所以如何將敏捷這些思想，灌輸給團隊。然後沿着方法論嘗試、總結、修改、再嘗試。

這樣的敏捷，我不確定是不是也是敏捷的一種。

總結

不斷實踐，不斷吸收，不斷激發，不斷優化

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

【其他文章推薦】

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

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

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

※南投搬家前需注意的眉眉角角，別等搬了再說!

澳洲野火肆虐動物缺糧政府空投糧食救援

2020-05-212020-05-21 admin

摘錄自2020年1月13日公視報導

澳洲最近野火燎原，專家估計至少有8億隻野生動物被燒死或受到影響，澳洲當局星期一宣布將投入5000萬澳幣，約合10億新台幣，作為搶救野生動物與復原棲地的經費，而在新南威爾斯則已經空投兩噸的蔬菜糧食，讓當地瀕危的刷尾袋鼠等物種果腹救命。

從直升機上將一箱箱紅蘿蔔和蕃薯空投到地面，攝影機隨後捕捉到小型瀕危的刷尾岩袋鼠現身，抱著救命的糧食啃了起來。為了搶救倖存的野生動物，相關單位已經在國家公園內空投兩噸的蔬菜糧食。

澳洲當局同時在星期一宣布將砸下5000萬澳幣，約合10億台幣，作為救助野生動物的經費，澳洲環境部長表示，其中一半將用於野生動物的醫療照顧與安置，並致力復原被野火燒毀的棲地；另一半將用來搶救面臨生存危機的野生動物。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

澳洲山火持續多月 NASA：煙塵快將環繞地球一周

2020-05-212020-05-21 admin

摘錄自2020年1月14日星島日報報導

美國太空總署（NASA）指出，澳洲山火造成的煙霧快將環繞地球一周。

NASA指出，元旦前後煙霧已越過南美，令南美國家天空變得朦朧，也嚴重影響紐西蘭。澳洲最近山火非常大，產生「異常多」的火積雲，火積雲使煙霧飛入平流層，其中有煙霧最長錄得17.7公里，煙霧就可飄到四方八面，影響全球大氣環境，部份已抵達智利。NASA稱，大量煙塵有機會形成火積雲，再產生閃電及引發新一輪大火。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

※南投搬家前需注意的眉眉角角，別等搬了再說!

新品牌效應台灣電動機車買氣加溫

2020-05-202020-05-20 admin

台灣中央與地方政府推動電動機車多年，今年因為新品牌Gogoro加入市場而加強了業者間的競爭意識，同時帶動了消費者的買氣。

Gogoro的電動機車Smartscooter今年七月正式上市。在十月祭出降價策略後，十月的銷售量達680輛，比九月成長了106%，已是當月台北市機車掛牌數量第四名。台北市是目前Gogoro相關服務最完善的地區，除了有較密集的電池交換站外，也開始嘗試與超商業者合作，讓騎士能以超商為據點交換電池。

在Gogoro加入市場後，台灣電動機車的需求整體也隨之升高。今年十月，台灣整體電動車掛牌輛創下2012年元月開始推行電動機車以來的新高；電動車相關概念股的股價也跟著成長，後勢可期。

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

【其他文章推薦】

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

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

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

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

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

中國電動車充電樁規模將超1300億

2020-05-202020-05-20 admin

據中國汽車工業協會的數據顯示，純電動汽車銷量最大，前三季度產銷分別完成20365輛和19228輛，同比分別增長2.7倍和2.9倍。《節能與新能源汽車產業發展規劃（2012—2020年）》的主要目標要求，產業化方面，到2015年，純電動汽車和插電式混合動力汽車累計產銷量力爭達到50萬輛；到2020年，純電動汽車和插電式混合動力汽車生產能力達200萬輛、累計產銷量超過500萬輛，燃料電池汽車、車用氫能源產業與國際同步發展。據國家能源局電力司副司長童光毅介紹，500萬輛電動汽車充電意味著需要建480萬個分散式充電樁、1.2萬座集中式充換電站。據此估算，未來每年將需建設至少96萬個充電樁，按照目前建設費用計，直接市場規模將超過1300億元。工信部公佈的數據顯示，國內已經建成723座充電站，充電樁配備量為2.8萬個。目前，充電設施與新能源汽車保有量比例維持在1∶4左右的水準，而標配為1∶1。無疑，充電樁的建設滯後是新能源汽車發展的軟肋。根據“十三五”規劃，預計到2020年，集中式充換電站將增長到1.2萬座，分散式充電樁數量將增長100倍達到450萬個。文章來源：科技日報

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

【其他文章推薦】

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

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

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

※南投搬家前需注意的眉眉角角，別等搬了再說!