フリーランス チャレンジ!!

フリーランス チャレンジ!!

現役フリーランスエンジニアが書く雑記ブログ

プロトタイプ作成やデモの時にWebページを直接変更する方法

chrome.google.com

 

プロトタイプ作成してる時、デモの時に他の人の意見を聞きながら、文字や色、フォントなど変更したい時ってありますよね?

 

そんな時に便利なのが、visbugというChromeで使える拡張機能。

 

 

visbugの簡単なデモ

まずは、一部機能の簡単なデモ動画を見てください。

※検索結果の3番目に表示されたこのブログ記事を1番目に移動しました。

 

youtu.be

 

インストール方法

インストール方法は簡単。

下記ページでChrome拡張を追加するだけ。

https://chrome.google.com/webstore/detail/visbug/cdockenadnadldjbbgcallicgledbeoc

 

機能紹介:Guides

f:id:ksakae1216:20190818203253p:plain

 

マウスカーソルを調べたい箇所の上に持ってくと要素を表示してくれます。

また、要素をクリックして、他の要素にカーソルを持ってくと最初にクリックした要素との距離をピクセル表示してくれます。

 

機能紹介:Inspect

f:id:ksakae1216:20190818210819p:plain

マウスカーソルで選択した要素のStyle(CSS)を表示してくれます。

 

またMacの場合、Optionキー押下して、クリックすると表示を残してくれます。

例えば、最初に選択した要素をOption+クリックして、別の要素をOptin+クリックすると最初と2番目をそのまま表示してくれるので見比べることができます。

 

機能紹介:Accessibility

f:id:ksakae1216:20190818210841p:plain

人が見て、どのくらい分かりやすいかをチェックするためのものっぽいです。

マウスカーソルで選択した箇所で出てくる数値が高ければ高いほど人の目に優しくて問題なければ緑色のチェックが表示され、問題があれば赤色でバツが表示されます。

 

機能紹介:Move

f:id:ksakae1216:20190818210855p:plain

要素の中で上下左右に対象の要素を移動できます。

例えば横にボタンが3つ並んでいたらそのボタンの順番を変更できます。

 

つまり要素の中だけで順番を変更できる感じです。

 

機能紹介:Margin

f:id:ksakae1216:20190818212100p:plain

要素を選択して、その後に上下左右ボタン押下でそれぞれのMarginを広げたり、狭めたりできます。

 

機能紹介:Padding

f:id:ksakae1216:20190818212208p:plain

要素を選択して、その後に上下左右ボタン押下でそれぞれのPaddingを広げたり、狭めたりできます。

 

機能紹介:Flexbox Align

f:id:ksakae1216:20190818212325p:plain

選択した要素のAlignを上下左右ボタン押下で変更することができます。 

 

機能紹介:Hue Shift

f:id:ksakae1216:20190818212914p:plain

選択した要素の色、背景色を上下左右ボタンで変更することができます。

要素は複数選択も可です。 

 

機能紹介:Shadow

f:id:ksakae1216:20190818212946p:plain

選択した要素の影を追加することができます。

こちらも上下左右ボタンで変更することが可能です。 

 

機能紹介:Position

f:id:ksakae1216:20190818213155p:plain

このブログのデモに紹介した機能です。

要素を移動できます。 

 

機能紹介:Font Styles

f:id:ksakae1216:20190818213922p:plain

選択した要素のフォントサイズ、Boldを変更できます。

こちらも上下左右ボタンで変更可能。 

 

機能紹介:Edit Text 

f:id:ksakae1216:20190818214117p:plain

選択した要素のテキストを変更する機能です。 

 

機能紹介:Search

f:id:ksakae1216:20190818214730p:plain

要素を検索できます。

検索ボックスに検索したいスタイルなどを入力し検索します。

また、▼ボタンからそのページで使われてる要素の候補から検索することもできます。

PostgreSQLも使える無償クライアントツールTablePlus(Mac, Windows対応)

tableplus.io

 

PostgreSQL用のクライアントツールでしかもMacとなるといいクライアントツールがないんだよね〜。

 

PG Commander, PSequel, TeamSQLとそれぞれ試してきたけど不満だらけ。。。

 

PG Commanderはテーブルの絞り込みができないし、SQLの補完もない。

PSequelは絞り込み、補完はできるけど、まだまだ機能不足。

TeamSQLは唯一良かったけど、使えなくなった。。。

DB接続のクライアントツールはTeamSQLで決まり(インストールからMySQL接続まで紹介) - フリーランス チャレンジ!!

 

そこで、無償でPostgreSQL(他のDBも使えるよ)で使えて多機能ですばらしいTablePlusを紹介します。

 

WindowsでもMacでも使えるのはうれしいよね!!

 

 

ダウンロード先

ここからダウンロードできます↓↓↓

TablePlus | Modern, Native Tool for Database Management

 

対応データベース

たくさんのデータベースに対応してます。

f:id:ksakae1216:20190814180120p:plain

・PostgreSQL

・MySQL

・Amazon Redshift

・Microsoft SQL Server

・SQLite

・MariaDB

・Oracle

・Redis

・Cassandra

・Cockroach

・MongoDB(Beta)

・Vertica

 ※MongoDBはBetaと書いてなるのでもしかしてまだ正式にサポートしてないかも。

 

SSH、秘密鍵も対応

SSH、秘密鍵も対応してます。

私も仕事で使ってますが、ローカルのVirtualBox、SSH接続するサーバー、AWSどれも接続できました。

 

接続方法の紹介

先に接続してから機能を紹介しようと思います。

接続方法に興味ない方は飛ばしてください。

 

「Create new connection」をクリック 

f:id:ksakae1216:20190814181548p:plain

 

 ここから対象のDBを選択します。

f:id:ksakae1216:20190814181811p:plain

 

接続情報を入力し、「Test」ボタンを押下します。

テスト接続が成功すればフィールドがこのように緑色になるので「Connect」ボタン押下でDB接続します。

f:id:ksakae1216:20190814182752p:plain

 

はい、接続できましたね。

それではこれから機能を紹介してきます。

f:id:ksakae1216:20190814183100p:plain

 

テーブルの絞りこみ

画面左上のテキストボックで絞り込むことができます。

ちょっと変わってるのが"ka"と入力すると"kanto_chiba", "kanto_tokyo"だけになりそうだと思いますが、"kyushu_fukuoka", "kyushu_kagoshima"もそのまま表示されます。

このテキストボックスは入力した文字全てに一致するテーブルが表示されるからです。

なのでこの場合、正規表現使って"^ka"とするか"kan"まで入力すれば"kanto"のテーブルが表示されます。

f:id:ksakae1216:20190814183909p:plain

 

データの修正、テーブル構成

テーブルをクリックするとそのテーブルの内容が表示されます。

変更したいデータをクリックすると編集できるので変更してEnter。

f:id:ksakae1216:20190814184403p:plain

 

するとテーブル名の背景が黄色になるのでMacならCmd + S押下で変更が反映されます。

f:id:ksakae1216:20190814184413p:plain

 

テーブルの構成は「Structure」をクリックすると見ることができます。

もちろんここで変更することもできます。

f:id:ksakae1216:20190814184703p:plain

 

SQL補完

SQLの補完も完璧です、赤矢印のSQLをクリックするとSQLビューが開きます。

f:id:ksakae1216:20190814185137p:plain

 

"sele"と打つとこのように補完候補が表示されます。

f:id:ksakae1216:20190814185618p:plain

 

テーブル名も同様に補完されます。

f:id:ksakae1216:20190814185651p:plain

 

ビューの右下にある「Run Current」ボタン押下でSQL実行。

「Beautify」ボタンでSQL文を整形もしてくれます。地味に便利。

 

複数のDB接続

 赤矢印のコンセントアイコンをクリックすると

f:id:ksakae1216:20190814190022p:plain

 

登録してある接続先一覧が出てくるので、もう1つのMySQLを選択します。

f:id:ksakae1216:20190814190225p:plain

 

はい、このようにPostgreSQL(postgres)、MySQL(test_mysql)の2つを接続できました。

それぞれクリックすることで表示を切り替えることができます。

f:id:ksakae1216:20190814190240p:plain

 

色の変更

地味に気に入ってるんですが、接続先を表示してあるバーの色を変えることができます。

私はMySQLの色を変更しました。

デフォルト色(灰色)のPostgreSQL

f:id:ksakae1216:20190814191017p:plain

 

色を変更したMySQL

ローカル環境とStaging環境みたいなことを視覚的にもわかりやすくできるのでいいですよね。

f:id:ksakae1216:20190814191045p:plain  

データのselect文作成

 この機能もあるとまあまあ助かるんですよね。

テーブルのデータを選択し、右クリック、「SQL Insert Statement」で選択したデータのInsert文をクリップボードにコピーしてくれます。

f:id:ksakae1216:20190814191148p:plain

 

テーブル右クリックでTruncateとテーブル削除

テーブル削除はあまり使わないですがTruncateってたまに使いますよね。

SQL文打つのもそんなに大変じゃないですが、マウス操作でできるのはうれしいです。

f:id:ksakae1216:20190814191324p:plain

  

無償版の注意点

ここまでメリットを中心に紹介しましたが最後に1点だけ無償版の注意点です。

 

無償版はテーブル、接続先を2つ以上開くと「Free Trial limited 2 tabs」と表示されます。

無償版はタブ2つまでだよということです。

なのでこまめにタブを閉じて使ってください。

タブを閉じるのはMacだとCmd + Wです。

Nxチュートリアルをやってみた(Step 3 〜 12)

前回記事の続きです。

Nxチュートリアルをやってみた(Add E2E Tests) - フリーランス チャレンジ!!

 

この記事ではチュートリアルのStep3から最後まで一気に紹介します。

今までは、最初だったので1つずつ丁寧に紹介しましたが、大分慣れてきたので各Stepのやること結果をピックアップして紹介。

 

 

 

Step 3: Display Todos

nx.dev

AppComponent.tsにtodos配列を定義。

画面側にもこのtodos配列の内容を表示するよう修正し、Cypressテストを実行、見事パスします。

 

Step4 Connect to API

nx.dev

 

AppComponentクラスにAPIにアクセスするコードを追加して、最後に画面表示です。

APIを受け取って返す処理がないので画面を表示してもコンソールには404 NotFoundが出力されます。

 

Step 5: Add Node Application Implementing API

nx.dev

 

nestアプリケーションを開発できる機能を追加。

nestを使用してAPIを作成して、コードを一部修正。

最後にAPIを起動してブラウザからURLを叩けば結果を返してくれる。

※チュートリアルは"https://localhost:3333/api/todos"となってるが本当は"http"。

  "https"だと表示できないので注意が必要。

 

Step 6: Proxy

nx.dev

 

Step5で作成したAPIのProxy設定を解説。

todos, apiをng serveで起動し画面が表示されることを確認。

APIを作成するまでは、todosはソースに直書きだったものがAPI経由で取得できるようになった。

 

Step 7: Share Code

 

nx.dev

 

todosインターフェースをフロント、バックエンド両方で定義してるのが問題なのでこのステップでインターフェースをシェアするように変更する。

インターフェース格納用のlibディレクトリをコマンドで作成し、インターフェースを定義。

その後、ng serveで画面起動して表示されることを確認。

 

Step 8: Create Libs

nx.dev

 

 UIライブラリを作成してtodosコンポーネントを作成。

 画面はそのコンポーネントの部品を使う感じ。

正直ここのチュートリアルだけだとコンポーネント部分のとこがイマイチ理解しきれない。

 

Step 9: Dep Graph

nx.dev

 

Nxの標準機能で依存関係をブラウザに表示することができます。

 

Step 10: Test Affected Projects 

nx.dev

 

"npm run affected:apps"で変更された内容を調べ、変更の影響を受ける可能性があるアプリを特定する。

 また、変更内容から影響の受ける可能性のある箇所をテストすることもできる"npm run affected:test"

あと、parallelオプションをつけるとtestをパラレルで実行してくれるのでテストがすぐ終わる。

 

Step 11: Build Affected Projects

nx.dev

 

"npm run affected:build"はtodosをビルドするがuiはビルドしない。

 

Step 12: Summary

nx.dev

 

ここまでのチュートリアルでやってきたことを振り返り

 

最後に

この記事でStep3から12まで一気にやってきました。

 

正直チュートリアルやっただけでNxを全て理解することはできませんが、少なくともNxを使えばしっかりしたテンプレートを自動的に作ってくれるのでしっかりした(?)アプリを作成することができる印象です。

Nxチュートリアルをやってみた(Add E2E Tests)

前回はnpx、ngコマンドでアプリケーションを作成しました。

今回はE2Eテスト(Cypress)をこのアプリケーションに追加します。

※NxはデフォルトでCypressが使えるよ。

 CypressってどんなE2Eテストか知りたかったら下記の記事をぜひ読んでみて。

簡単、速い、テストの動画保存、Cypressは最高のe2eテストだ!! - フリーランス チャレンジ!!

 

 

チュートリアル

このページです。

nx.dev

 

チュートリアル前にテスト実行

前回の記事で作成したアプリのテストを起動します。

 

テスト実行コマンド

gist0f781f571dd2c7f3ce5e856e8b9549f5

 

IDEが立ち上がるので画面右の「Run all specs」ボタンを押下。

f:id:ksakae1216:20190709204707p:plain

 

はい、テスト成功です。

f:id:ksakae1216:20190709205055p:plain

 

テスト内容の解説

テストが成功しましたが、どんなテストだったか解説します。

 

gist177e3d812a5b41e17c78fc6980619fa3

定数(const)で"getGreeting"を定義して"h1"タグをセットしてます。

Cypressで使えるAPIは下記を参照して下さい。

get | Cypress Documentation

 

gist3260c97f95315c3e38e942c5ef57838b

次はテストコードです。

 

・1行目で先ほどの定数ファイルをimport

・4行目の"cy.visit('/'));"で画面を開き

・7行目でh1タグに"Welcome to todos!"が含まれてるかチェック

 

もう一度、テスト結果画面の左部分を再掲します。

コードを説明した通りのテストとなってます。

f:id:ksakae1216:20190722225740p:plain

 

どうですか?

直感的でわかりやすいですよね?

 

テストコードを追加 

gist739c4ed2e6bb6d91c8596fb7a5a22968

 

ボタンに関する定数"getAddTodoButton"を追加。

 

gistd52f019606fd691255a35c012ef4e215

 

テストコードもチュートリアルに合わせて大幅に変更してます。

 

e2eテスト実行

それでは変更したコードでe2eテストを実行してみます。

f:id:ksakae1216:20190727170517p:plain

 

テスト失敗です。

”expected 0 to equal 2”がテスト失敗の部分です。 

 

最後に

このチュートリアルはテストを追加するが失敗するのがゴールとなります。

このチュートリアルにも書いてありますが、チュートリアルを進めてくとこのテストも合格するようになるそうです。

 

ソースコードは下記を参照ください。

github.com

 

 

 

 

Nxチュートリアルをやってみた(Create Application)

f:id:ksakae1216:20190615173336p:plain

Nxチュートリアルをやってみた!!

 

その前にNxって何?って人もいるよね。

実は私もこのチュートリアルやる前にそんな状態でした。

プロジェクトで使ってるけど、内容理解してなくて。。。

 

まずはそこから調べて、チュートリアルを進めてきます。

 

 

Nxって何?

まずは公式ページを見てみる。

nx.dev

 

Use Modern Tools

Use Modern Tools

Using Nx, you can add Cypress, Jest, Prettier, and Nest into your dev workflow. Nx sets up these tools and allows you to use them seamlessly. These innovative tools offer a lot of advantages and help you work better and smarter.

 

(翻訳)

Nxを使用すると、開発ワークフローにサイプレス、ジェスト、プリティー、ネストを追加できます。 Nxはこれらのツールをセットアップし、それらをシームレスに使用できるようにします。これらの革新的なツールは多くの利点を提供し、あなたがより良くそしてより賢く働くのを助けます。 もっと詳しく知る

 

Cypressはe2eテストランナー、JestはFacebookが作ったテストランナー、Prettierはコード整形(フォーマット)、NestはNodeJsフレームワーク(サーバー側もTypeScriptで書こうみたいな)です。

 

上記で上げたこれらのツールを使えるようにできるってこと。

 

Build Full-Stack Applications

Build Full-Stack Applications


With Nx, you can build full-stack applications using Angular and Node.js frameworks such as Nest and Express. You can share code between the frontend and the backend. And you can use the familiar ng build/test/serve commands to power the whole

 

(翻訳) 

Nxでは、NestやExpressなどのAngularおよびNode.jsフレームワークを使用してフルスタックアプリケーションを構築できます。フロントエンドとバックエンドの間でコードを共有できます。そして、あなたは全体に力を与えるためにおなじみのng build / test / serveコマンドを使うことができます。 

 

さっき出てきたNestの話ですね。

バックもTypeScriptで書けるのでバックエンドと同じようにコードを書くことができるということです。

フロントとバックが同じTypeScriptで書けるのは開発者にとってだいぶ楽になりますね。

 

Develop Like Google

 

Develop Like Google

With Nx, you can develop multiple full-stack applications holistically and share code between them all in the same workspace. Nx provides advanced tools which help you scale your enterprise development. Nx helps enforce your organization’s standards and community best practices.

 

(翻訳)

Nxを使用すると、複数のフルスタックアプリケーションを総合的に開発し、それらの間でコードをすべて同じワークスペースで共有できます。

Nxはあなたがあなたのエンタープライズ開発を拡大するのを助ける高度なツールを提供します。 Nxは、組織の標準とコミュニティのベストプラクティスを強化するのに役立ちます。

 

正直翻訳しても内容が理解できないですがタイトルは「Googleのように開発する」となってるのできっとGoogleのように開発できるんでしょう。

 

長くなりましたが便利なテストランナー、コードフォーマット、サーバー側もTypeScriptで書けてGoogleのように開発できるのがNxのようです。

 

チュートリアルやってみた(Create Application)

 それではようやくチュートリアルです。

下記ページを参考にチュートリアルを実施してみます。

Step 1: Create Application

 

workspace作成

gistb00f694d843ca15731db67ee2a861f36

 

f:id:ksakae1216:20190615215120p:plain

 

途中で、何回か聞かれます、「CSS」と「empty」を選択しました。

完了するとmyorgディレクトリにとその下にいろいろ作成されます。

f:id:ksakae1216:20190615215806p:plain

 

アプリケーション作成

gist5e5038233f91e707f5774ca6cde4e350

 

f:id:ksakae1216:20190615215819p:plain

 

gist4107c6272f3c99353236c9a915cf69f5

 

f:id:ksakae1216:20190615220109p:plain

 

todoアプリケーションが作成されました。

 

アプリケーション起動

gist1a0e3d91902a78fdee481336d907c6f8

 

localhost:4200に接続すると、アプリが起動されてることがわかります。

f:id:ksakae1216:20190615220533p:plain

 

最後に

このチュートリアルでわかったことは、applicationコマンドでアプリが簡単に作成できたことです。

この後続いてチュートリアルを実施していきたいと思います。

 

github.com

簡単、速い、テストの動画保存、Cypressは最高のe2eテストだ!!

www.cypress.io

インストールが簡単、速いe2eテスト、テストを動画で保存するなど、素晴らしいe2eテストツールのCypress!!

 

Cypressとはどんなツールなのか?

実際にインストールしてテスト書いて実行するとこまで紹介します。

 

Githubにもソースを登録するので簡単に試してみたい方はgit cloneしてe2eテストやってみてください!!

 

e2eテストやった事ない人は本当に感動するし、今後テストも書いていこうって思えますよ!!!

 

 

Cypressとは?

以下の特徴があります。

・インストールがとても簡単

・テストが速い(らしい)

・テスト過程を自動で動画保存

・CI連携

・テスト用IDEがある

・テストの補助(selector)がある 

 

ただし、現在Chromeしか対応してないのでクロスブラウザが必須の人は他のテストツールを探してください。

 

e2eテストは動作の保証ができればOKな人は、ぜひこのCypressをお試しください。

いいテストツールですよ!!

 

Cypressインストール

コマンド1つでインストールOK!!

gistd82e4148b16b802246f5c8ad532e9107

 

後、下記のコマンドでCypressの雛形を作成してくれます。

gist86b15f9fa22489ee81b63328a8d962cf

 

作成される雛形、Cypressフォルダが作成されます。

f:id:ksakae1216:20190610230201p:plain

 

ちなみにprotractorのe2eテストがそのプロジェクトにすでにある場合、下記の削除する質問で'Y'を入力すればprotoractorのe2eテストを削除してくれます。

f:id:ksakae1216:20190610230012p:plain

 

テストの書き方 

cypress/integrationフォルダ配下にテストファイルを作成して テストを書きます。

 

まず1つサンプルから、ログイン画面を表示できるか確認するテスト。

gistc25420def06dc01d3ef8d7f5149fd9f5

 

'cy.' + APIでテストを書くことができます。

このサンプルでは'cy.visit(ログイン画面URL)'でログイン画面を表示できる事をテストします。

 

APIは下記を参照してください(英語だけど。。。)

Table of Contents | Cypress Documentation

 

e2eテスト失敗

まずは失敗ケースを見てみましょう。

Cypressはe2eテスト実行すると、画面のスクリーンショットと動画を保存してくれるのでどこで、どのようにテストが落ちたか簡単に確認することができます。

 

'npm run start'しないでテストするので画面が起動できず失敗するテスト。

 

【スクリーンショット】

 cypress/screenshotsフォルダにスクリーンショットがテスト毎にあります。

f:id:ksakae1216:20190611213415p:plain

 

テスト失敗のスクリーンショット

f:id:ksakae1216:20190611220841p:plain

 

【動画保存】

cypress/videosの下にテスト毎の動画。

f:id:ksakae1216:20190611221134p:plain 

 

e2eテスト実行(cypress run)

次は正常のe2eテストです。

こちらは普通のe2eテストを想定してもらえればOKです。

 

実際のテストを実行した動画です。


Cypress e2e run

 

e2eテスト実行(cypress open)

次は対話モード 、こちらも動画で紹介。

テストランナーが起動するまで時間がかかるので起動後の動画です。


Cypress e2e open

 

この記事のソースと実行方法

github.com

 

下記コマンドの通り、cloneしてテスト実行できます。

gist52d280ff4f289d8629922095b9e11bb8

 

超一流プログラマーの3つの共通点は「英語」、「公式リファレンス」、「とにかくコード書く」ですね

超一流 プログラマー 共通点 英語 公式リファレンス コード書く

IT業界で働くこと20年弱。

 

今までたくさんのプログラマーに出会ってきた。

 

超一流プログラマー、できるプログラマー、普通のプログラマー、できないプログラマーと大体4つくらいに分けられる。

※ちなみに超一流プログラマーはGoogleとかにいるのかもしれないけど、そんなとことは縁がないので私が会ってきた中でとにかくすごかった人を超一流としてます。

 

それぞれの比率は大体こんな感じだと思う。

02%:超一流プログラマー

08%:できるプログラマー

50%:普通のプログラマー

40%:できないプログラマー

 

そして出会ってきた超一流プログラマーはみんな

・英語ができる

・公式リファレンスをみる

・とにかくコード書く

感じだったんです。

 

自分の中の整理の意味も込めてそれぞれのプログラマーの共通点をまとめてみました。

 

 

超一流プログラマーの共通点

冒頭にも書いたけど、「英語」、「公式リファレンス」、「とにかくコードを書く」の3つ。

 

英語ができるので、情報を入手するのは英語のページから。

日本語だけと違い英語ができると、入手する情報の早さ、正確さが全然違う。

 

技術的な記事で日本語が一番先に出ることはなく、基本英語での記事が一番早いです。

Googleにしろ、Microsoftにしろ、オープンソース系にしろ全部英語記事が一番早い。

 

英語ができれば情報量、情報の早さが格段に違う。

 

 

次に公式リファレンスなんかも基本英語。

日本語訳があるとこもたまにあるけど、基本英語ですよね。

 

英語できる人はちゃんと公式リファレンス見ます。

英語ができない私なんかは、英語のリファレンスを無理やりGoogle翻訳してみるけど、意味をあまり理解できずQiitaとかに頼っちゃう。

 

公式リファレンス以外だと、結構ウソ情報が多いので超一流プログラマーは必ず公式ふリファレンスを見ますね。

 

 

最後にとにかくコード書きます。

できる人って結局、普通の人の何倍も作業してるんですね。

 

平日、仕事終わった後自宅で。

休日、朝から夜まで。

趣味はプログラム。

みたいな。

 

本人も楽しんでやってるので、「趣味はプログラム」って言いそうな。

そのくらい普通の人より何倍もコード書いてる。

 

そりゃ勝てないよって感じです。

 

できるプログラマーの共通点

頭が良くて、作業量多い人ですね。

 

周りを見回しても、他と段違いで頭が良く回転が早い人。

 

その上、作業量も多い。

 

超一流プログラマーと違って自宅でも四六時中プログラム書くことはないが(それでも普通の人よりは書いてる)、会社では人よりも長く残業してプログラム書いてるタイプ。

 

普通のプログラマーの共通点

そこそこプログラム好きで自宅でも多少プログラムするタイプ。

 

プログラムは好きだし、技術的なキャッチアップもするが会社でもそんなに残業しないし、自宅でもたまにプログラム書く程度。

 

できないプログラマーの共通点

 ここまでに書いた共通点が無い人ですね。

 

ただ共通点を挙げるとしたらこれかな?

・多分、そんなにプログラムが好きじゃない。

・分からないことを調べたり解決するのも好きじゃない。

・仕事でお金もらえるからやってる。

 

分からないことは人に聞いて解決したり、意味も理解せずどっかからソースコード持ってきてコピペ済ませたり、とりあえず動けばいいや系。

 

現場によるけど、技術者のレベルが低い現場に行くとこの手の人が結構います。

逆に技術レベルが普通以上だと少数派。

 

最後に

どうですかね??

 

超一流と呼ばれるプログラマーの共通点について違う意見があれば教えて欲しいです。

SEだったら当然知ってるよね? PDCAじゃなくOODAループの事を

ooda pdca

(出典:Wikipediaより)
 

「PDCA知ってる?」、「PDCAやったことある?」ってよく聞かれると思うけど「OODA知ってる?」って聞かれる事はあまりないんじゃないかな〜と思います。

 

が、手段としてOODAループってとても有効だから知らない人はぜひ、この記事読んでOODAループを知ってらいたい。

 

 

OODAとは?

以下の4つのプロセスをループし、意思決定して動く事です。

・観察(Observe)

・状況判断(Orient)

・意思決定(Decide)

・実行(Act)

 

観察(Observe)

状況の観察で改善する事、したい事を観察します。

 

観察とは見て観察するだけでなく、データを収集する事も含まれます。

できれば事前バイアスがかからないよう生のデータを収集することが大切です。

 

状況判断(Orient)

観察結果、収集したデータから仮説を立てます。

 

仮説を立てるのが難しい場合もありますが、無理矢理でもいいので仮説を立ててください。

 

意思決定(Decide)

立てた仮説を元に、どのように実行していくか検討します。

 

収集したデータ、仮説からいくつか実行方法を考え、一番効果的なものを選択するのが良いでしょう。

 

実行(Act)

意思決定(Decide)で導き出した一番効果的と思われる方法を実行します。

 

 

PDCAとの違い

大きな違いは、やる事が分かっているか分かってないかです。

 

PDCAはやることが分かっているのでPlan(計画)を立てることができますがOODAの場合は、やる事が分かってないので観察(Observe)、状況判断(Orient)のやる事を導き出すプロセスがあります。

 

そもそもPDCAとOODAはどちらが良いかというのもなく、それぞれ使われるケースが異なるのです。

 

「方向性の決まってるソフトウェアプロダクト」や、「会社の知名度を上げるため広告を打つ」など明確な方向性が決まってる場合は、PDCAを選択し

 

「顧客満足度を上げたい」や、「ソフトウェアの品質を上げたい」などのゴールはあるが明確な方向性が決まってない場合は、OODAを選択します。

 

このようにPDCAとOODAは使われるケースが全然違うんです。

 

だからPDCAとOODAを比較する事はなく、それぞれにマッチするケースでPDCAかOODAを選択すれば良いのです。 

 

OODAループを使った例

実際に私が関わったプロジェクトを例にします。

 

【ゴール】

開発効率を上げたい

 

【観察(Observe)】

どこに開発のボトルネックがあるか観察しました。

 

観察内容としては月あたりの

・開発チケット数

・予定通りに終わったチケット数

・予定通りに終わらなかったチケット数

・リリースしたがバグになった件数

を観察する事とし、チケットの件数はRedmineから、予定通りに終わらない、バグになった件数は日々のやり取りメールから集計しました。

 

【状況判断(Orient)】

集計したデータを元に以下の判断をしました。

・開発チケット数が開発メンバーに対して多いか少ないかは判断が難しい

・予定通りに終わらないチケットがそこそこある印象

・2週間に1回リリースしてるが5、6件リリースして1件のバグが発生する確率が2回に1回くらいある。(ちょっと多いかな)

・開発プロセスを確認したら、製造者とテスト担当者が同じでソースコードレビューも忙しさを理由に簡単にすませてる事があった。

 

【意思決定(Decide)】

状況を見た結果、開発メンバーに対して現在の開発ペースが速いか遅いかは判断が難しく、バグを減らして、バグに対応する時間を開発に使うのがいいんじゃないかという判断になりました。

 

バグを減らすために考えたことは

「テスト、レビューをしっかりして開発プロセス正す事」

 

テスト、レビューをしっかりすると今までよりも時間はかかるがバグが無くなれば結果的に時間を節約できると考えました。

 

そこで、正しく開発できるプロセスを考え、そのプロセスを開発リーダーにレビューしてもらい実行できるレベルまでプロセスを作り上げた。 

 

【Act(実行)】

 あとは、正しい開発プロセスを適用して開発してもらった。

 

このような施策はすぐに効果が出るわけではなく長い目で見なければいけない。

 

しかも、ここで終わりではなく、プロセスを適用した結果を観察し次のOODAループでどんどん改善していく事が重要です。

 

OODAループがチカラを発揮するケース

「開発効率を上げたい」、「品質を上げたい」などゴールはあるが計画(Plan)が無い場合に大きなチカラを発揮します。

 

計画(Plan)が無いのに無理やりPDCAを適用すれば間違った計画・行動になってしまい効果が出るまで時間がかかってしまいます。

 

なので計画がない場合は、OODAを適用し何回もループさせて素早くゴールにたどり着きましょう!!

勉強できる人が必ずしも仕事ができるわけではない

勉強できる人 仕事

勉強できる人は、問題を解決できる問題解決力があるから仕事もできると思ってた。

 

仕事はまさに問題を解決する事が目的だから。

 

でも大手SIにいた時、有名大学を卒業した勉強ができてた人をたくさん見てきたが仕事ができない人もまあまあいた。

 

なぜ勉強はできたのに仕事ができないのか?

 

勉強には正解があるが、仕事には正解が無いからではないかと思った。

 

 

勉強には正解がある

勉強の場合、教科書か、参考書か、先生のどこかに正解がある。

 

問題の載っている教科書とテストの答え(解決方法)は、教科書、参考書、先生のどこかにある。

 

答え(解決方法)の無い問題は勉強には出てこない。

 

なので、どんな問題に出くわしても答え(解決方法)が無い事はなく、分からなければ教科書、参考書、先生のどれかに当たれば、必ず解決する。

 

仕事には正解がない

しかし、仕事には正解が無い。

 

会社で問題に出くわした場合、会社の資料、ネット、先輩(上司)に当たると思うけど、正解が無い場合も多い。

 

正解のある仕事もまあまああるけど、正解のない仕事(まずはこれでやってみよう)が結構ある。

 

正解もなければ、パターンも無く、毎度毎度、違うパターンの問題が発生する事も多々ある。

 

勉強できるが仕事できる人、できない人の違い

勉強できる人は往々にして問題解決力があり、分からない事は調べ、考え、応用して問題を解決する作業を多くしてきた。

 

考える時間も多く、難しい問題を解決してきたので勉強できる人の問題解決力は、相当鍛えられてるはずだ。

 

そんな問題解決力がある人がなぜ仕事ができないのか?

 

それは、「正解が無い」事が原因ではないか?

 

仕事には正解が無いので、正解が無いまま突き進む事ができない。

 

有名な大学を出てて仕事ができない人を何人か見てきたが、正解が無い仕事に対して「これでやってみよう」が上手くできない。

 

勉強だったら正解があるので、応用問題も勉強した解決方法を駆使して解けるのだが仕事の場合は、解決方法がないので、自分で解決方法を考え、実践するのが苦手なようだ。

解決方法を考えるのも苦手だし、考えた解決方法も的を得てない。

 

逆に勉強できて仕事ができる人は、自分で解決方法を考え、実践するのが得意だ。 

 

現在分かってる事、分かってない事を整理し、ロジカルに仕事を進める事ができる。

 

勉強できるのに仕事ができる人、できない人の差は、「解決方法を考える事ができるか、できないかの違い」なのではないか。

 

自分は勉強できない方だったので、何で勉強できるのに解決方法考えるのが不得意なのか、勉強できる人に教えてもらいたい。

【A day in the Life of a Engineer】世界のエンジニアの1日に密着

A day in the LIfe of a Enginner 世界 エンジニア

YouTubeを見てたときにたまたま発見したんだけど、エンジニアの1日に密着したシリーズ(?)みたいなのがあって、とても面白かったのでオススメの5点を紹介します。

 

これを見れば世界のエンジニアがどのように働いてるか分かりますよ。

 

A day in the Life of a Engineer

 

 

SAPエンジニア(6分)


one day in life of SAP software engineer

 

【特徴】

・イケメン

・おしゃれ

・仕事楽しそう

 

【1日のタイムテーブル】

06:22 起床

07:00 朝食

09:00 出社してコーディング

10:00 チームミーティング

12:00 外出(トレーニング)

13:10 昼食

14:20 コーディング

16:45 コーヒー飲みながらミーティング

19:00 報告会

19:48 帰宅&友人達と飲み

23:00 Finish

 

フロントエンジニア(7分)


a day in the life of a software engineer

 

【特徴】

・自宅で仕事

・筋トレ多め

・仕事時間少なめ(3時間)、勉強多め

 

【1日のタイムテーブル】

05:00 起床

05:15 仕事(フロントエンド開発)

08:00 朝食

09:00 勉強(Team Programming)

13:00 外出して筋トレ

15:15 昼食

16:00 フリータイム(Flutter勉強)

21:00 読書

22:00 就寝

 

ソフトウェアエンジニア(3分)


A Day In The Life Of A Computer Software Engineer - Vlog

 

【特徴】

・こまめに休憩とってる感じ

・食事しながら仕事してる(ちょっと意外)

・職場に犬がいる

 

【1日のタイムテーブル】

07:00 起床

07:50 自宅出発

08:04 オフィス到着

08:15 朝食&メールチェック

08:35 コーディング

10:00 チームでコーヒータイム

10:13 ワーク

12:03 ランチを取りにいく

12:14 ランチしながら仕事

14:00 ミーティング

15:10 チームでCHAIタイム

15:31 デザイン

17:10 スナックタイム

18:50 帰宅(ジムへ)

22:29 就寝

 

最後に

働いてる時間は日本とあまり変わらないですが、日本と違って出社から退社まで働きっぱなしじゃなく、休憩をちょこちょこ入れてるのが大きな違いですね。

 

うらやましい〜〜