taisablog

taisa's engineer blog

IMG_1569

投稿日:

-

執筆者:

関連記事

AWS Summit Tokyo 2017:Day2 参加レポ

AWS Summit Tokyo 2017 Day2の参加レポ。そもそも私はこれまでAWS Summit参加したことがなく、AWSについてもこれから本格的に使っていこうとしている段階なので自分にとっては大変為になるサミットだった。 ※ 以下の内容については参加時メモが元になっているので一部誤っている箇所があるかもしれないですがご容赦ください。動画やスライドがあがってくれば確認できるのですがまだ見つけられなかったので確認ができませんでした。 基調講演 まず基調講演会場に入って真っ先に思ったのはめっちゃ広い!!ってこととめっちゃ豪華!!ってこと。この先もそうだけどこれが無料で参加できるなんてさすがAmazon様。という感じだった。 基調講演会場入った。めっちゃ広い。 #AWSSummit pic.twitter.com/E6bqTMVoEu — たいさ (@taisa831) May 31, 2017 オープニング 基調講演は三味線・バイオリン・ギターのスペシャルライブから始まった。これはめちゃくちゃよくてもっと聞いていたかった。 AWS Summit Tokyo スペシャルバンドによる演奏でAWS Summit Tokyo 2017 Day2 基調講演がはじまりました!#AWSSummit pic.twitter.com/SMkfuUfRIG — アマゾン ウェブ サービス (@awscloud_jp) May 31, 2017 アマゾン ウェブ サービス ジャパン 長崎忠雄 オープニングのスペジャルライブが終わりホストスピーカーとしてAWS Japan代表取締役社長が出てきた。スピーチは社長らしく今回は去年と違って規模が約2倍であることやAWSのこれまでの成長・現状そしてこれからの未来について話された。あとサービスコンソールが6月末まえに100%日本語化すると明言していたのにはちょっと驚いた。厳密には以降ホストとゲストが入れ替わってスピーチしていたがスピーチメモは以下まとめて記載する メモ 今回のサミットはRegistration 20,000人以上(世界で一番多い?) 去年の2倍の規模 スタートアップ企業の支援を強化してる 事例大全集ダウンロードできる ユーザコミュニティあるしエンタープライズ版もある サービスコンソールを6月末までに100%日本語化予定 現在90以上のサービスがある 2016年には1017の新サービスおよび機能改善数(数年前は100程度だった) Amazon AIすごいよってことでルービックキューブ動画を再生 パターンが多いので普通なら35年ほどかかるのがこれを使うと0.9秒になるよ 他にもマシンラーニングを導入した企業のコスト削減の紹介 コスト1億円削減したり10日かかってたのが10分に削減したり 5/31からAmazon LightsailがTokyoリージョンで使えるようになる(データ転送量込みで月額5ドルから) いろんな企業にとってデータの移行の課題が大きい AWS Database Migration ServiceでDBを簡単に移行ができるので現在25,000以上が移行済みである ペタバイト級のデータ移行もあるけどそんな場合はAWS Snowballが利用できる AWSサポート充実してる(ベーシック・開発者向け・エンタープライズ向けなど) コストダウンについて これまで2006年のサービスインから明確な競合がいないにもかかわらず61回の値下げをしてる これはユーザファーストであることの表れである オンプレからAWSとのハイブリットのつなぎを重要視 フルマネージドサービスで運用負荷軽減 災害に対するリスクは高い(日本では2018にOsaka Regionが利用可能になる予定) セキュリティとコンプライアンスをファーストプライオリティとしている ゲストスピーカー/三菱UFJファイナンシャルグループ 村林 聡 まず初めのゲストスピーカーは三菱UFJファイナンシャルグループ執行役専務グループCIO。まず最初に自分たちはレガシーな企業だと2回程念を押すように言ったのち、これからはデジタルトランスフォーメーション、オープンイノベーションへ向かっていくという話をされた。具体的にはAPI、BlockChain、AIなどを駆使し7年後には銀行のコアの業務を4割ほどをAIに置き換えられるのではないかと。また、現在はオンプレから順次AWSへサーバ移行中で、現在は5つ程稼働しているが、100程が移行検討中である。ただ最後に今期で退任して次のところへ行きますといって締めていったのでなんとも言えない空気になった。 メモ デジタルトランスフォーメーション、オープンイノベーションへ オンプレから移行予定 AWSでは現在稼働中5つ(100くらい検討中) 今期で退任する ゲストスピーカー/セイコーエプソン 熊倉一徳 続いてのゲストスピーカーはセイコーエプソン株式会社のIT推進本部 本部長が登壇。セイコーエプソンは創業当時からものづくりの企業でありリアルな世界にこれからも提供していくのは変わらないといった一方で現在はサイバー空間も重要視し力を入れている。 メモ ものづくりの企業 リアルな世界に提供するのは変わらない サイバー空間も重要視 クラウドへの移行はかなり困難だった サーバレスアーキテクチャを採用 ゲストスピーカー/レコチョク 稲荷 …

Git 2.9でdiffがちょっとかしこくなった

ちょっと前にはなるがGit 2.9がリリースされてdiffがちょっとかしこくなった。 リリースノート Git 2.9 Release Notes 記事 Git 2.9 has been releasedGit2.9のキレイなdiffを出すためのconfig diffをいままでよりいい感じにする git diffに「–compaction-heuristic」オプションを追加するかgit configに「diff.compactionHeuristic true」を設定することで、これまでdiffがコンフリクト起こして正しく出せてなかったケースをカバーするようになった。今回のリリースではオプションつけるか設定変更する必要があるけど後々デフォルトになる予定とのこと。ちなみにほんとかな?と記事のソースで新旧バージョンで比較してみたところしっかり解消されてました。はいすいません。オプションつける場合 git diff –compaction-heuristic コンフィグに設定する場合 git config –global diff.compactionHeuristic true ハイライトもこれまでよりいい感じにできる diff-highlightでは同行の文字変更を見やすくするというものだけどこれ自体は以前からあった。ではどこが変わったかというと、これまでごく一部でハイライトできなかったけどそれ解消したよってことだと思う。でこっちも設定変える必要あるよとのこと。設定がなければ追加 git config –global pager.log ‘diff-highlight | less’ git config –global pager.show ‘diff-highlight | less’ git config –global pager.diff ‘diff-highlight | less’ 今回のリリースで追加された新しい設定 git config interactive.diffFilter diff-highlight ということで今回のリリースによって.gitconfigに設定が追加された。 [diff] compactionHeuristic = true [interactive] diffFilter = diff-highlight

プログラミング言語の歴史を見える化してみた

「まつもとゆきひろ 言語のしくみ」と「Talk Python #100」のGuidoの回をたまたま同時期に見聞きしたら言語の歴史を調べたくなった。言語は少なからず他の言語から影響を受けたり、他の言語に影響を与えたりしている。ということでその影響関係をwikipediaの情報を元に見える化してみた。 まつもとゆきひろ 言語のしくみ ぐちゃ〜。。。これだけ見ると複雑に絡み合ってよくわからない。ただ見たい言語をクリックするとその言語がフォーカスされどの言語がどの言語に影響を与えどの言語に影響を受けたかが見やすくなる。 使い方 ソースはこちら GitHub taisa831/Langury Contribute to Langury development by creating an account on GitHub. 多重継承が可能なC++で(ただクラスをつくってるだけ)doxygenとgraphvizを使って出力している。 インストール DoxygenとGraphvizをインストールする。 brew install doxygen brew install graphviz Languryをクローンする。 git clone git@github.com:taisa831/Langury.git cd Langury 出力 doxygenコマンドを実行してHTMLを出力して開く。 doxygen open html/index.html select Classes -> Class Hierarchy 対象言語 ここで取り上げた言語はwikipediaの以下を対象にした。 ※一部記載なし。 ※実際とは異なっていたり足りてない箇所があるご注意ください。 各言語について 1950年代:FORTRAN、LISP、ALGOL、COBOL 1960年代:CPL、BASIC、PL/I、BCPL、Simula、LOGO、B 1970年代:Forth、Pascal、C、Prolog、Smalltalk、ML、AWK、Ada 1980年代:C++、Objective-C、Common Lisp、Eiffel、Erlang、Perl 1990年代:Python、Tcl/Tk、Haskell、Visual Basic、Ruby、Lua、Delphi、Java、JavaScript、PHP、OCaml、SuperCollider、R 2000年代:C#、Scala、D、F#、Go 2010年代:Ceylon、Rust、Dart、Elixir、Hack、Swift 1950年代 FORTRAN 1954年にIBMのジョン・バッカスによって考案された。コンピュータにおいて広く使われたプログラミング史上最初の高水準言語。 LISP 1958年にジョン・マッカーシーによってはじめて設計された。高水準プログラミング言語の中ではFORTRANに次いで2番目に古い。LISPの名前は「list processor」に由来している。 ALGOL 1950年代中ごろに開発され、多くの言語に影響を及ぼした。ACMや教科書や学術論文などでアルゴリズム記述のデファクトスタンダードとして30年以上使われ、ほぼ同世代の高水準言語であるFORTRAN、LISP、COBOLに比べて最も成功した。設計者はバウアー、 ルティシュハウザー、 サメルソン、 バッカス、 パリス、 ナウア、 ファン・ワインハールデン、 マッカーシー他。FORTRANで明らかとなった問題を防ぐよう設計された。「ALGOL」は「アルゴリズム言語」を意味する英語「algorithmic language」に由来する。 COBOL 1959年に事務処理用に開発されたプログラミング言語。名前は「Common Business Oriented Language」(共通事務処理用言語)に由来する。 1960年代 CPL CPLはケンブリッジ大学の数学研究所とロンドン大学コンピュータ部の共同プロジェクトとして1960年代に開発された。C言語の遠い祖先となった言語でクリストファー・ストレイチーが関与している。Combined Programming Language「統合プログラミング言語」の意。 BASIC 1964年に米国ダートマス大学にて数学者ジョン・ケメニーとトーマス・カーツにより教育用などを目的としてダートマスBASICが開発された。初心者向けのプログラミング言語として、1970年代以降のコンピュータ(特にパソコン)で広く使われた。Windowsアプリケーションの主力な開発言語であるVisual Basicの文法に影を残している。 PL/I 1964年に生まれ。教育機関、商用、工業で使用され現在も使われている。「programming language one」(ピーエルワン)に由来する。 BCPL Basic Combined Programming Language、Basic-CPLは、1966年にケンブリッジ大学のマーチン・リチャーズが設計した。B言語の基礎で、B言語から派生したC言語は文法的にBCPLの亜種。 Simula オルヨハン・ダールとクリステン・ニガードによってALGOL60を拡張する形で1960年代に開発が始められたシミュレーション用途のプログラミング言語(登場時期は1967年)。世界最初のオブジェクト指向言語であると言われる。 …

スクラムガイド

スクラムを3ヶ月やってみて

スクラムを初めて3ヶ月たったので振り返る スクラムについて スクラム (ソフトウェア開発) – wikipedia スクラム(英: Scrum)は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと 一定の周期で計画会議→開発(スプリント)、スプリントレビュー、クロージング(振り返り、リリース)を繰り返すことが大事 スクラムを始めたきっかけ 前まで マネージャーの管理コストが高い 開発メンバーが今なにやってるかを把握するのが大変 リリースサイクルが決まっていない為開発、営業、運用の連携が困難 開発したものが放置されやすい 突発的な開発対応に追われる 開発者は言われたものだけをひたすら開発するというサイクルになりがち スクラム体制後 マネージャーの管理コストが下がる 開発チームがなにやってるかを把握できる リリースサイクルが決まる為営業、運用、開発の連携がしやすい 品質が上がる 振り返りによりチーム力が上がる 開発が考えるシナリオを推進することができる 開発チーム個々が自発的に行動できる デメリット 運用などの担当者が必要で担当者がかたよる スクラム体制について 1スプリント2週間、クロージング1週間とする プロダクトオーナー スクラムマスター(自分) 開発チーム4人 ミドルエンジニア 若手ベトナムエンジニア 新卒ベトナムエンジニア 新卒エンジニア スプリント振り返り 1月中旬から始めて3スプリントを実施した。 スプリント1(1/16〜1/27) 機能概要 データ解析+グラフ化 Good/Keep 設計レビューにより実装前の軌道修正ができる 開発チーム+スクラムマスターのレビューにより各自の実装の認識をあわせる プロダクトオーナーレビューにより更に違った目線からの指摘があり最終的な実装の認識をあわせる 設計段階で認識を合わせることにより品質があがる為トータルコストがよい 画面を伴う機能は特に設計レビューによる効果が大きい 設計レビューでアウトプットの認識があうのでビジネスへのアプローチがしやすくなる テスト環境すら整ってない新卒エンジニアがモックテストまでできるようになった 局所的なハンズオンやペアプロは効果が高い スクラムは各自のスキルアップに効果的 Problem プロダクトオーナーとスクラムマスター以外がスクラムの取り組みにおいて受動的 ドキュメント・テストケースの書き方の各自の認識が違う Trelloの更新がうまくできなかった JavaScript処理が複雑 Try GitFlowに切り替えるにあたりバージョニングを検討した セマンティックバージョニングにしたかったがメンバー全員に周知し徹底することが難しいと判断し文字列でタグ付けすることとした チームメンバ全員がモックを使ったPHPUnitが書けるようになったので全員UTを書く開発体制にした ドキュメントの書き方の認識をあわせた JavaScriptの構成やフレームワーク変更を検討する スプリント2(2/6〜2/17) 機能概要 画面レイアウト変更 レポート系 Good/Keep クロスブラウザ・端末テストなどマンパワーを要するテストをみんなで分担してできる為テストが楽で早く終えられる チームメンバー全員がモックテストがかけて開発コードのほとんど(不要な部分は除く)のカバレッジをカバーできている 設計レビューの恩恵 要件定義時に認識があっていたと思っても設計すると認識がずれていたりするがレビューの中で最適な解を見つけることができる 実装前のレビューで懸念点をつぶしてながら設計できるのが気持ちいい 実装前にの実装イメージが具体的に湧く為テストが書きやすい 設計後実装の分担をするとテストを先に書けるケースが出てくる 開発チームが各自自発的に行動するようになった Problem ドキュメント作成に時間がかかる コーディングスタイルの指摘が多い 最初に作成したスプリントバックログの作業量をオーバーした タスクの粒が大きいと初日のスプリントバックログ作成の時間だけでは正確な見積もりができないことがわかった Try 計画会議とプロダクトバックログ作成を1日で実施した 翌日以降の個人の動きが明確になり個々人が個別に自主的に動ける デイリースクラムにスクラムマスターが参加しないようにした コードフォーマットチェック(php-cs-fixer)をgitのpre-commitに導入した php-cs-fixer導入参考ブログ WIPを導入した 次回以降はもっとIF・クラス設計に重点を置いて開発する方針にした スプリント3(2/27〜3/10) 機能概要 機能の外部埋込プラグイン Good/Keep 失敗覚悟でギリギリのベロシティのタスクを設定したところ色々新しい課題がみえた 開発メンバ各自の実機テスト環境を改善した 既存バグの修正ができた 課題 タスクの難易度があがるとコミュニケーションコストがかなり高くなる 受け入れ条件の範囲を超えた作業をした為余計に時間を費やした 2週間という期間にしばられて品質を落とす形になった コミュニケーションコストを見積もりに入れてなかった …

2019年の抱負

本業頑張るのはもとより、2019年の抱負がある程度固まってきたので書いておきます。 Google Cloud Platformを使う これまでAWSを自分で多く触るケースはあまりありませんでしたが、GCPを使うケースが増えてきたので今年からはAWSではなくGCPをたくさん触っていこうと思います。 数学をやる 高校3年になるまでは大学行く気もなく全く授業をまともに受けていませんでした。高校2年の終わり頃に少しまじめに授業を受けるようになり、少しずつ数学が楽しくなってきた頃大学進学も視野に入ってきました。そんなときに自分が文系を選択していたことを知り、私立受験は英国社の三教科であることを知り(国立など受験の仕組みすら知らず)、そこで自分の数学学習人生は終わりました。そんなこんなで今までやってきたのですが、ふと最近以下の投稿をみてなんとなくやってみようかなと思いはじめました。記事のようにAIや機械学習の為ということも少しはありますが、自分としてはただの興味ですのでどこまでやれるかはわかりませんが、今小学中学の復習を終え数I・Aをちらちらみはじめています。 文系エンジニアが機械学習に入門するために小学校の算数から高校数学までを一気に復習してみました。 宅建をとる 今の本業が不動産テックということもありますが、これもただ興味が出てきたのでやってみようかなという感じです。宅建みやざき塾というYoutube動画が秀逸なので今はこの動画を移動中などにみています。 体力をつける 小さい子供が2人いると休日にランニングすることもままならないので去年は体重がかなり増えてしまいました。運動ができてないだけでなく、肩こりなど疲れやすい状態になっていたのでこれを今年は改善しようと思います。最近は食事や運動を気にしつつ「長生き味噌汁」をはじめました。 まとめ どこに向かっているのかという感じはありますが、本業で事業を伸ばすことを頑張りつつこれらをやっていこうと思います。