2016年振り返り

今年一年の振り返り

全然更新できていないのだけれど、やりたいことは沢山あったし、やりたいことが全然できていない一年。

フロントエンド

一番やりたかったのはangular(angular2)。チュートリアルやったぐらい。これだけ書ければフロントはいけそうだし、angular1に比べてコード見やすいし。

サーバサイド

nodeやりたかったけれど、仕事で.net使ってるのもあって、asp.net coreへ方向転換。ただそのあとすぐに忙しくなって止まってる。

ニュースとかブログは読んでるけれど、アウトプットが無さすぎて自分の中に残ってない感が多い。
まず来年は時間を作るところから。

PostgreSQLへASP.NET CoreとEntity Frameworkでアクセスしてみる

asp.net MVCを使えるようになりたいと思い少し触ってみました。
asp.netは仕事でWebFormを使ったことがあるだけです。

自宅にはmacしかないので、.net coreを選択したのですが、かなりハマりました。
このエントリーを見つけたおかげで、
なんとか動かすところまではできたのでそのメモです。

前提

  • .Net Coreがインストール済み
  • Visual Studio Codeがインストール済み
  • PostgreSQLがインストール済み
  • node、npm、yeome、generator-aspnetインストール済み

動かすまでにやったこと

  1. テンプレートの作成(ターミナルで実行)

    • yo aspnetコマンドを実行
    • Web Application Basic [without Membership and Authorization]を選択
    • プロジェクトの名前を入力。(今回はsample1を入力)
    • プロジェクトが作成されたら、下記コマンドを入力するように出るので、その通りにコマンドを実行

        cd "sample1"
        dotnet restore
        dotnet build
        dotnet run
      
    • dotnet runが成功するとURLが表示されるので、ブラウザでそのURLへアクセス

      • http://localhost:5000
    • 無事起動すれば準備完了
  2. project.jsonへEntityFrameworkを追加

    • dependenciesへ下記を追加

      "Npgsql.EntityFrameworkCore.PostgreSQL": "1.0.0"
      "Microsoft.EntityFrameworkCore.Design": "1.0.0-preview2-final"
      
    • toolsへ下記を追加

      "Microsoft.EntityFrameworkCore.Tools": {
          "version": "1.0.0-preview2-final",
          "imports": "portable-net45+win8+dnxcore50"
      }
      
  3. ModelクラスとDbContextの作成

    • Modelsフォルダを作成
    • Articleクラス(Article.cs)
    • Authorクラス(Author.cs)
    • ArticleContextクラス(ArticleContext.cs)

    ソースはリンク先のとおりなので省略。
    変更した点は、各クラスを別ファイルにしたのと、
    namespaceをnamespace sample1にしたこと。

  4. appsettings.jsonへDB接続情報を記載

     {
         "DbContextSettings" :{
             "ConnectionString" : "User ID=postgresのユーザ;Password=パスワード;Host=localhost;Port=5432;Database=DemoArticlesApp;Pooling=true;"
         }
     }
    
  5. Startup.csへDbContextを追加

    • ConfigureServicesに下記を追加
      もともとservices.AddMvc();の記載があるのでその下に追記

        var connectionString = Configuration["DbContextSettings:ConnectionString"];
        services.AddDbContext<ArticleContext>(
            opts => opts.UseNpgsql(connectionString)
        );
      
  6. migrationの実行

    • sample1フォルダをターミナルで開いて、下記コマンドを実行

        dotnet ef migrations add InitialMigration
        dotnet ef database update
      
  7. migrationが成功しているか確認

    • ターミナルで下記コマンドを実行

        psql DemoArticlesApp -c "SELECT table_name FROM Information_Schema.tables where table_schema='public'"
      
    • 3テーブルが作成されていればOK

        table_name
        -----------------------
         __EFMigrationsHistory
        Authors
        Articles
        (3 rows)
      
  8. Controllerを作成

    • Controllerはyo asp:MvcControllerコマンドで作成

        yo aspnet:MvcController AuthorsController
      
    • AuthorsControllerのソースはリンク先そのままなので省略。(namespaceだけnamespace sample1に変更)

  9. アプリケーション実行

    • ターミナルからdotnet run
    • Chrome拡張機能のPostmanを使って動作確認

      • POSTするときにデータフォーマットはrawにして、JSON(application/json)にする
    • ブラウザのアドレスバーにhttp://localhost:5000/api/authors/1を入れて、POSTで登録したデータが取得できるか確認。

最後に

かなりざっくりだけれど、これでapi叩いて追加、参照はできるようになりました。
asp.net MVCもEntity Frameworkもわからない状態で始めたので、
試行錯誤を繰り返して動かすまでかなり大変でした。

ようやく動かせるようになったので、内容はこれから理解していきます。

Elixirで単純なパターンマッチにハマりました。

前々からElixirに興味があったので、プログラミングElixirを購入しました。

プログラミングElixir

プログラミングElixir


第2章のパターンマッチでまで読んだのだけれど、理解できないところが。
(この記事を書いていたら解決したけれど、せっかく書いたので残しておきます。)

分からなかったのは2章の「練習問題PatternMatching-1」で、 結果がどうなるのかというもの。

a = [ [1, 2, 3]]
[a] = [ [1, 2, 3]]
[ [a] ] = [ [1, 2, 3] ]


一つ目はすぐに分かったのだけれど、二つ目、三つ目が分からなかった。

一つ目は、aは[ [1, 2, 3]]に束縛される。
これは見たままなので簡単。

二つ目は、aは[1, 2, 3]に束縛される。
三つ目は、MatchErrorになる。

ぱっと見何これ?と思ったのだけれど、一段ずつリストを取り出して考えれば簡単に分かりました。
三つ目の場合でいうと、

[ [a] ] = [ [1, 2, 3] ]
↓
[a] = [1, 2, 3]
↓
a = 1, 2, 3

左辺は値(a)が一つだけれど、右辺は1, 2, 3の3つ。
左辺と右辺で値の個数が違うためエラー。
二つ目も同じように考えれば、[1, 2, 3]になるのは納得。

上記みたいに考えれば簡単だけれど、最初式だけ見たときは全然理解できなくて、何これ?と思ってしまいました。

理解できたので引き続き3章以降も読み進めていこう。

アジャイル開発の研修メモ

会社でアジャイル開発の研修を受けさせてもらったのでそのメモ。
メモっただけで理解できていないことなどが多いので、後々調べて理解していく。

研修が終わって一番重要だと感じたのは、アジャイルな開発手法を導入することよりも、
アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則 )」が、チームや経営陣に理解されないと成功しないだろうと感じた。

そこも含めてアジャイルの導入なんだろうけれど。

以下からは研修のメモ書き。


プロジェクト失敗の要因

  • ユーザのインプット不足
  • 不完全な要求事項と仕様
  • 要求事項と仕様の変更
  • 経営者の支援不足

ウォーターフォール型開発の前提

  • 顧客の要求は予め明確になっている
  • 顧客の要求は開発者側に正確に伝わる
  • 顧客の要求は大きく変更されない
  • プロジェクト計画に従えば予定どおり進む
  • 前工程には間違いがない

アジャイル開発とは

  • 反復
  • 漸進的
  • 適応
  • 自律的
  • 多能工
  • 強調

アジャイルソフトウェア開発宣言

アジャイルソフトウェア開発宣言

アジャイル開発の価値観の共有
共通の概念や考え方を広く社会に知らせる

  • プロセスやツールよりも⇨個人と対話を
    • 尊敬の気持ち
    • お互いの信頼感
    • 自由にやり取りする雰囲気
    • 良いコミュニケーション
    • 透明性
    • 目標に対する貢献
  • 包括的なドキュメントよりも⇨動くソフトウェアを
    • 顧客が要求する実行可能な状態のソフトウェア
    • 正しく機能するソフトウェアを一定の間隔で提供
  • 契約交渉よりも⇨顧客との協調を
    • 顧客のプロジェクトチームへの参加
    • 顧客との緊密なコラボレーションの方法や仕組みの導入
  • 計画に従うことよりも⇨変化への対応を
    • 顧客の要求は始めから全てを明確に定義できない
    • 変更があるのは当たり前であるという前提で柔軟に対応

アジャイルマニフェスト 12の原則

アジャイル宣言の背後にある原則

アジャイル開発の特徴

  • 反復・漸進型開発
    • 設計・開発・テストを繰り返し開発
  • ドキュメントより動くソフトウェア
    • 顧客の要求は事前に明確に定義できない
    • 必要なドキュメントは最小限に
    • 顧客との対話を重視しながら要求を明確に
    • 動くソフトウェアのもとで品質管理
  • 顧客との協調
    • プロジェクトの開発時点では、その後の全てを見通すことはできない
    • 反復開始毎に優先的に開発すべき要求を顧客と一緒に決めて実行
    • 顧客のプロジェクトへの参加は必須
  • 変更に柔軟に対応
    • 開発中もビジネス環境が変化して要求自体も変わってくる
    • 変更があるのは当たり前
    • ビジネス価値を上げる要求は歓迎
    • 全ての要求が自由ではない
  • 個人間の相互作用「自己組織的チーム」
    • チーム自身が責任をもって、自律的にプロジェクトを運営
    • 問題意識や目的を共有
    • それぞれの相互作用による知恵の出し合い
    • ひとつの組織としての意思決定
  • ペア・プログラミング
    • 技術の共有
    • 質の高いプログラミング
    • コード全体の問題点とメンバー特性の共通認識
    • ドライバーとナビゲーター
  • テスト駆動開発
    • 最初にテスト項目を決め、動作する必要最低限の実装をまず行う
    • 次にコードを洗練させる
    • XPで多く用いられる

ウォーターフォール型開発との比較

ウォーターフォール アジャイル
成功の指標 計画に合致 変化に対応、正常に動くコード
要求と設計 前もって、大きく 継続的、その都度適切な内容を定義
コーディングとテスト すべての機能を順番にコーディングし、後でテスト コーディングと単体テスト、連続的にリリース
テストと品質保証 計画主体、最後にテスト 並行的、継続的、早期にテスト
管理の文化 命令と管理 リーダーシップ、コラボレーション

アジャイル適用の効果(顧客視点)

  • 早期に導入効果を実現
  • すべての要求が決まらなくても着手可能
  • リスクを早期に軽減
  • 高い投資効果(80:20の法則)
  • Time to Market向上
  • 変化への対応が容易

アジャイル適用の効果(受託企業視点)

  • リスクの早期発見
  • 動くソフトウェアの早期リリース
  • 頻繁な反復による品質向上
  • モチベーション向上と高い生産性
    • 顧客の役に立ったという達成感
    • 自らの責任で計画を立てて実行するためやらされ感がない
  • 開発者の能力向上
  • 残業からの解放
    • 自分たちの開発能力から見て達成可能な計画を自主的に立てる
  • ムダの削減
    • 手戻りがなくなる
    • face to faceのコミュニケーション重視のため、「不要」なドキュメントは作らない
  • 振り返りによる継続的改善

アジャイルのプロセス

スクラムの原点

  • 新製品開発ゲーム
    • 高いパフォーマンス⇨少人数の組織横断的なチーム
    • ラグビースクラムのような自己組織チーム⇨組織の障害要因が取り除かれれば、より高品質なソフトウェアを提供可
  • リーン生産方式
    • リーン:痩せた、贅肉のないの意味
    • 必要な時に必要なものを必要なだけ作り、在庫を寝かせずフル回転させるジャストインタイムのカンバン方式
    • 自ら仕事の結果をチェックし、異常はその場で解決し、次工程に持ち越さない
    • 多能工、目で見て管理、目標を掲げ改善を継続

      スクラムの精神

  • スクラム
    • 反復的な開発アプローチ 動くソフトウェアを順次作り、発展させながら開発を進める
    • タイムボックス:すべての作業や会議は規定された時間内に完了。
    • 目標の共有:目標を共有し、自ら方向性を定め、日々の時間管理をし、改善する
    • 固定したチーム:メンバーは専任。交代せず固定化した体制で臨む。
  • 確約(Commitment):約束したことを確実に実現すること
  • 専念(Focus):確約したことの実現に専念すること
  • 格差ない(Open):たとえ自分に不利なことでも包み隠さないこと
  • 尊敬(Respect):自分と異なる人に敬意を払うこと
  • 勇気(Courage)確約し、隠さず、敬意を払うことに勇気を持つこと
  • スクラムチーム
    • プロダクトオーナー
      • プロダクトの要求事項の定義
      • プロダクトのリリース計画と内容の決定
      • プロダクトの収益性、投資回収性の責任
      • 要求事項の優先順位付け(ビジネス価値・リスク)
      • 作業結果の評価・判断
    • 開発チーム
      • プロダクトの要求事項を反復ごとに納品
      • プロダクトオーナーに品質と納期をコミット
      • 組織横断的チーム活動
      • 自己組織的チーム活動
      • 継続的プロセス改善
    • スクラムマスター
      • 開発チームを自己組織的チームに育成
      • 開発チームの反復活動を支援
      • 開発チームの機能向上、品質向上、生産性向上を支援
      • 開発チームのコラボレーション促進
      • 進捗の阻害要因を除去
      • 開発チームに対して指示・管理は行わない
  • スクラム開発の流れ
    1. リリース計画
    2. プロダクトバックログ (開発対象の動くソフトウェアに関するすべての要求機能が一覧になったもの)
    3. スプリント計画ミーティング
    4. スプリントバックログ (プロダクトバックログを動作するソフトウェアとして実装するために必要な作業のリスト)
    5. デイリースクラム (毎日のミーティング)
    6. スプリント
    7. スプリントレビューミーティング
    8. スプリントレトロスペクティブミーティング
  • リリース計画
    • プロジェクトビジョン
      • 戦略性:ビジネスの価値、差別化要素
      • 目的:システムで実現したいこと
      • プロジェクトスコープ:プロジェクトの全体像
      • 機能・性能:システムにして欲しいこと
    • 要求機能の表現方法
      • ユーザーストーリー
  • プロダクトバックログ
    • 開発要求リスト
    • 優先順位
    • 常時開示
  • スプリント計画ミーティング
    • スプリントゴール どの要求を構築するか
    • スプリントバックログ 選択した項目をタスクに分解
  • スプリントバックログ
    • プロダクトバックログを実装するために必要な作業のリスト
    • 担当するタスクはメンバー自らが選択
  • デイリースクラム
    • 日時の15分程度のミーティング
    • 昨日は何をしたか、今日の予定、今抱えている課題
  • スプリント
    • 最大30日
    • 各スプリントの長さは同一
    • 作業に専念できる環境にすること
      • チーム以外の人は、スプリント中にチームが行っている作業の範囲を変更することはできない
      • チーム以外の人は、スプリントに昨日や技術を追加してはならない
      • チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
      • チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
    • バーンダウンチャート 源氏あの状況をモニターし、どれだけの作業が残っているかを視覚的に分かりやすく表示
  • スプリントレビューミーティング
    • 動くソフトウェアが完了基準を満たしているか
    • プロダクト・オーナーからのフィードバックと受け入れの判断をしてもらう
    • 結果をプロダクトバックログに反映、ソフトウェア全体の完了日を予測
    • プロダクトバックログの内容と優先度の見直し
  • スプリントレトロスペクティブミーティング
    • 振り返り
    • 続けたいことと改善したいことをチーム全員で共有
    • 話題の対象は開発に関わる全てのこと
    • 開発チームが自主運営
    • 自由闊達になんでも話し合える

エンタープライズアジャイル

エンタープライズアジャイルとは

  • アメリカを中心に海外ではビジネス、ITの分野で広く普及している
  • 2001年のアジャイル宣言
  • 変化するビジネスニーズへ、より迅速、的確に対応
  • ITを通じてお客様のビジネス価値向上

普及への仮題

ハイブリッド開発

  • ハイブリッド開発の例
  • アジャイル開発に向くプロジェクト
    • 要求が事前に定めにくいプロジェクト
    • 革新的、実験的、経験がない分野のプロジェクト
    • 顧客が積極的に参加出来るプロジェクト
    • スキルが高く、高いモチベーションと専門性を持ったチームが編成できるプロジェクト
    • 日々チーム内及び顧客との緊密なコラボレーションができるプロジェクト
  • ウォーターフォール型開発に向くITプロジェクト
    • 事前に要求がほぼ確定できるプロジェクト
      • 基幹系業務、感情系業務
    • 厳格な変更管理が要求されるプロジェクト
    • 広範囲のドキュメントが要求されるプロジェクト
    • 法律や規則へのコンプライアンスが要求されるプロジェクト
    • 主要な役割に未経験者を割り当てしないといけないプロジェクト
      • 人材不足なプロジェクトってこと?
    • 顧客やエンドユーザのプロジェクト参画が制限されるプロエクト
    • 分散開発環境のプロジェクト
      • 複数のベンダーが関わるとか?

アジャイル開発のメリット

  • 顧客側
    • 頻繁な反復レビューにより、プロジェクトの進捗状況がわかるため安心感がある
      • 顧客がシステム開発に理解があれば良いけれど、そうじゃない場合は発注したんだからあとはちゃんと作ってになりそう
    • 反復レビューとフィードバックによって価値のあるシステムとなり、満足度が向上する
    • 開発の終盤まで要求仕様が検討できる
  • 開発側のメリット
    • 頻繁な反復レビューによって、リスクを早期に検知できる
    • 頻繁な反復テストによって、品質が向上する
    • 仕様追加があっても柔軟に予算と納期に対応出来る
      • 予算増えるの?納期変えられるの?どうやって?
    • 開発に投入するマンパワーの平坦化

チーム発展

  • チームとは
    • 共通の目的、達成すべき目標、そのためのアプローチを共有し、連帯責任を果たせる補完的なスキルを備えた人の集合体。
  • チーム発展段階モデル
    1. 成長期
    2. 動乱期
    3. 安定期
    4. 遂行期 自己組織的チームになる
  • 自己組織的チーム
    • お互いの信頼
    • 共通の目標を一緒に協力して達成する
    • 自由裁量権あるいは権限移譲されたチーム
    • チーム自ら意思決定する
    • チームは計画実行をコミットする
    • 情報はオープンで共有かされている
    • 建設的な反対意見は歓迎される
    • メンバーの役割は明確である
    • メンバーは高いモチベーションを持っている
    • マネージャーはチームをコントロールするのでなく支援する
    • プロセスは継続的に改善がなされる
    • 対話を重視する
    • お互いが助け合う
    • お互いが学び合う

アジャイルとリーダーシップ

  • アジャイルを成功に導くリーダーシップ
    • 感情の知性(EQ Emotional Intelligence Quotient)
      • 感情の状況を理解し、それをうまくコントロールする能力
      • 人の言動や行動は、その時々の感情の状態に大きく影響される
      • 良い人間関係
      • EQは適切な訓練によって高められる
      • 自分の今の感情の状態を認識し、それをコントロール
      • 相手の今の感情の状態を認識する
    • コミュニケーション
      • 個人との対話を
      • 顧客との協議を
      • 動くソフトウェアを
    • 共同作業とチームワーク
      • チームワークの善し悪しが開発業務の成否を左右する
    • ビジョン
      • プロジェクトが進むゴールを明確に示す
      • ゴールの共有
    • ファシリテーション
    • 他者の成長
    • コンフリクトマネジメント
      • 効果的なコンフリクトは必要、コンフリクトを有効活用する
    • 柔軟性
      • 変化へ柔軟に対応
  • 指示管理型リーダーシップとコラボレーション型リーダーシップ
    • モチベーション
      • 指示管理型:大きな権力を持ちたい
      • コラボレーション型:他者の役に立ちたい
    • マインドセット
      • 指示管理型:競争を勝ち抜き自分が賞賛される
      • コラボレーション型:強調とWIN/WINを重視
    • 影響力
      • 指示管理型:自分の権力を行使して畏怖させて動かす
      • コラボレーション型:信頼関係を気づき、自律性を重視、説得して動かす
    • コミュニケーションスタイル
      • 指示管理型:他者に対して命令、指示することを重視
      • コラボレーション型:他者の話を傾聴することを重視。
    • 業務遂行能力
      • 指示管理型:自分自身の能力向上で得られた自信をベースに他者に指示する
      • コラボレーション型:他者の育成、ともに学習することにより能力向上
    • 成長についての考え方
      • 指示管理型:しゃない制度等を利用することで自分の地位を上げ、成長していく
      • コラボレーション型:他者のやる気を大切に考え、個人と組織の成長の協調を考える
    • 責任についての考え方
      • 指示管理型:責任とは、失敗した時にその人を罰するためにある
      • コラボレーション型:責任を明確にすることで、失敗からも学ぶ
  • サーバント・リーダーシップとは
    • リーダーシップのスタイル
    • 5つの柱、11の特徴
      1. 奉仕の精神
        • 奉仕
          • 使命感:使命感を持って下から支える
          • 導き:共通のゴールに向かい導き、組織と人を動かす
      2. 対人関係力
        • 傾聴
          • 最後まで話を聴く
          • 相手の方を向いて聴く
          • 相槌を打つ
          • 黙ってもせかさない
          • 体全体で聴く(顔の表情、しぐさまで含めて)
          • 相手の発するシグナルをきちんと受け止める
          • 相手の言葉の奥底に潜む本筋と感情を理解する
          • 相手から自分の話を聴いてもらえるという姿勢
          • 的確な質問で、相手の意図を引き出す
        • 共感
          • 他人の感情、軽々ん、問題を理解する。あるいは共有する能力
          • 期待値を理解する
          • イメージ力を強化する
          • 共鳴しあえる共通の価値観の見い出し
          • 相手が欲している、困っていることを理解するため相手との架け橋を作る
          • 感じたことを相手に伝える優しさを持つ
          • 相手は共感してほしい、共感したいと思っている。自分の感情も相手に伝えてみる。
        • 気づき
          • 自分自身、組織、スタッフすべてに気を配る
          • メンバーに対する気づき
          • プロジェクトに関する気づき
          • 自分自身に対する気づき
          • 何が問題で何をすべきか
          • 刻々と変化する女うっ今日にたえず敏感になる
          • 自分自身の能力や限界を理解し、他人の意見に耳を傾け自己開発に努める
        • 癒し
          • 相手にかけているもの、木津ついていることを見つけ出し助言を与える
          • かけている部分を見つけたら、すぐに誘いの手を差し伸べる
          • ねぎらいと感謝の気持ちで接する
          • かけていることを悪と捉えない
      3. ビジョン
        • 概念化
          • 目指すゴールの絵を描く
          • 達成可能な大きな目標を立て、具体的な手順を列挙する
          • メンバーには結果責任を負わせながらも、目標達成ん向け自ら模範を示し、導く
        • 先見力・予見力
          • 目的地までどうやって行くかを示す力
          • 通常ルートと何かが起こった時のルートを予見する
          • リーダーは、行き方を常に見直しながら、何が起きるか察知して適切な判断を適宜下す
          • 洞察力を付ける
            • 直感的に判断する力
      4. モチベーション
        • スチュワードシップ
          • 大切なものを任せても信頼できると思われるような行動
          • 権力・理屈などに依存せず黙々と自分の役割の遂行に浸る
          • その人の背中を見て人々が自然と付いてくるような行動・姿勢
          • 組織の大きなゴールに応えるためには自己犠牲も厭わない
        • 説得
          • あることを相手に説明し、納得してもらい、相手に行動を自発的に起こしてもらう
          • 権限に依存することなく、服従を強要しない
          • 納得してもらい、共通のコンセンサスを確立する
          • 説き伏せるのではなく、自発的にゴール・ミッションを納得してもらう
          • 相手の言うことに耳を傾けながら、自分自身の意見も主張し相手にわかってもらうの力が必要
      5. 成長
        • 人々の成長へのコミット
          • メンバー一人一人に目をかけ、人間的にもキャリア的にも成長することをコミット
            • 定期的な面談、現場研修への積極的な参加、グループディスカッションを実施
            • メンバーの成長意欲を満たし、サポートする
          • 自分勝手な選り好みはしない
          • リーダーの役割はメンバーがゴールを達成するのを助けること
          • メンバーのパーソナルスキル、プロフェッショナルスキルの開発
          • 効果的なフィードバックを行い、さらなる成長のためのニーズを見つけ出す
          • 開発チームの一人一人の少しづつの成長がチームの成長になり大きなパワーになっていく
        • コミュニティづくり
          • 情報、計画、資源を共有しながら共同作業をする
          • 友好的、協力的雰囲気を作り出す
          • 自らが尊敬、助け合い、強調の模範となる
          • 積極的、情熱的なコミットメントを喚起し、チームを一体感ある集団にする
          • 顕密な人間関係を作り上げることに時間をかける
          • まずは、開発チームというコミュニティを念頭に置く

bootstrap-datepickerのサンプル

datepickerで年月の入力と範囲入力をする必要があったので、
公式ページを見つつサンプルを作ってみました。

サンプル見て書くだけなんだけれど、普段フロントエンドを書いていないので、単純なところでつまずいたり。
普段から少しでもコードを書くのは大事ですね。

つまずいた所は、下記の内容。 カレンダーのテキストボックスがロード前だから、datepickerが設定されず、のポップアップが表示されなかった。

動かなかったソース

<script>
        $('#date-yymm').datepicker({

動いたソース

<script>
      $(function(){
        $('#date-yymm').datepicker({


作ったサンプル
ソースコード(github)

github pages初めて使ったけど、静的ページなら楽に試せてよい感じ。

ストックビジネスの教科書

ストックビジネスの教科書を読んだので内容を自分用にメモ。

読んだ目的としては、自分の考えているストックビジネスの定義を確認したかったから。

結論は書いてあることと自身の考えに大差なかったので、本から得た新しい知識は少なかった。
ストックビジネスという事に少しでも知識があるなら読まなくてもいいかも。逆に全く知らなければ、1日かからずに読めるので読んでみてもいいかも。


以下は読んだ時のメモ。

ストックビジネスの定義

  • 継続的にお金(売上、利益)が入る
  • そのビジネスを人に売ることができる(個人に依存していない(人脈、職人的な技術等))

ビジネスモデル

ストックビジネスのビジネスモデルは下記17個。

  1. インフラ型
  2. 賃貸契約型
  3. レンタル・リース型
  4. ASP
  5. スポーツクラブ型
  6. 定期メンテナンス型
  7. 定期購入型
  8. フランチャイズ
  9. 協会認定型
  10. 消耗品購入型
  11. 予約サービス型
  12. 教室型
  13. サービス型
  14. 回数限定継続型
  15. 会員制型
  16. セキュリティー型
  17. 友の会型

課金モデル

課金モデルは下記8個。
上記ビジネスモデルと課金モデルの組み合わせでビジネスとなる。

  1. 固定課金
  2. 固定レンタル料課金
  3. ロイヤリティ課金
  4. 認定料課金
  5. 消耗品課金
  6. 利用分課金
  7. 定期購読
  8. 積立課金

商品デザインのアプローチ

  • コンテンツの質を重視するアプローチ
  • ビジネスモデル重視型のアプローチ

商品への課金をやめさせない仕組み

  • コンテンツの質を高める
  • やめる理由がない金額を設定する
    • 安ければやめるのが手間でやめない
      • 個人的には求めらるコンテンツだからやめないってのがいいけれど。
  • 定期的にコンテンツにプラスアルファを投入する
  • 提供する数を限定する
    • 会員限定&限数100とかだと、後から会員になればいいやって人が会員になる
    • 限数にすることで常に需要過多な状況にしておく
  • コミュニケーション回数を増やす

内容とは関係ないけれど、kindle版がなかったから、図書館で借りて読んだ。
個人的には紙しか無いから買わないってことが増えてるから、kindle版無いのもったい無いな。

ストックビジネスの教科書

ストックビジネスの教科書

ソフトウェア技術者サミット in 福井 2016に参加してきました。

2016/7/16に行われた、「ソフトウェア技術者サミット in 福井 2016」に参加してきました。 とっても刺激を受ける話が多かったです。
福井でのこういうイベント増えるといいな。

以下はメモ

クラウド時代のエンジニアについて

鈴木 雄介さんの「 クラウド時代のエンジニアについて」。

  • クラウドになることで開発が早くなるわけでは無い。サービスの運営が早くなる。
    クラウドにするとそれに伴うコードの変更は必ず発生する。
    使うライブラリを変えればコードも修正しないといけないという例はわかりやすかった。

  • ブルーグリーンデプロイ、カナリアリリース、ダークカナリア、カオスモンキー
    ダークカナリアとカオスモンキーは初めて聞いた。
    カオスモンキーはオンプレでの開発に慣れているとカオスに感じるけれど、クラウドの特性を考えると結構普通な考え方な気がした。

  • 技術の使われ方を意識する なぜその技術を使うのかというのは大事。

  • スペシャリスト or ジェネラリスト
    中途半端ではうまくいかない。どちらかに特化が必要。

  • ビジネスの中心にエンジニア
    ビジネスを実現するための技術なので、そこにエンジニアがいないのはおかしいし、そこに居られるようにビジネススキルを持つことが必要。

Windows開発者のための継続的デプロイ on AWS

福井 厚さんのAWSについての話。

  • AWS使ったことなかったから、へーって思うことばかり ほとんどの操作がVisual Studioからできる。
  • 資料公開してもらえるのかな

良い設計とアーキテクチャ

小井土 亨さんの設計について

  • 最初にみんなで演習
    内容は、朝JR福井駅を出てその日のお昼前にJR東京へ着くための調べ方を書くというもの。
    自分は乗換案内アプリで、出発駅:福井、到着駅:東京、到着時間:11時30分って入れるでした。
  • 正しい設計かどうかは、答えが合っているかどうかだけでは分からない。
  • テストしやすいものは良い傾向がある

エンジニア諸氏に勧めたいふたつの冒険

中西 孝之さんのお話。

  • Xamarinはいいぞ
  • アウトプット大事。
  • こういう場で30分発表してみる。
  • 敷居が高ければLT。
  • さらに高ければハッカソン
  • もくもく会っていうのもあるよ。ふくもく会。

「Live Coding で学ぶ C# 7」

鈴木 孝明さんのC#7でのライブコーディング

  • C#自体あまり知らないけれど、コード書いているのを見ると楽しい。
  • タプル書き方は楽そう。

テスト駆動開発ライブ〜C#ペアプログラミング実況中継」

平鍋 健児さんと小島 富治さんでのTDDのペアプロ

  • まずは失敗するテストコードを書いてから実装していく
  • 実装はテストが通る最低限の実装
  • テストが通ったらハイタッチ!
  • Visual Studioの電球は使っていく
  • 百聞は一見にしかずで、TDDがどういうものかすごくわかりやすかった

アーキテクト パネル「~アーキテクトが語るソフトウェア開発で大切なこと~」

モデレーター 福井 厚さん、小島 富治雄さん
パネラー 鈴木 雄介さん、小井土 亨さん、平鍋健児さん

  • 好きなもの、極められるものを持つ
  • 最後までやりきれること大事
  • コードを読む
  • 基礎の積み重ね
  • 東京で働かなくとも、東京へ人に人へ会いに行く
  • 技術を選択した理由を説明できるの大事。できないなら技術を使いたいだけの可能性がある。

LT

福井産業支援センターの河野 大さん

  • ふくいソフトウェア コンペティションの紹介
  • 学生の人は作ったものをアウトプットするという意味で参加するのもいいのでは
  • コンペティションとは別にアイデアソン、ハッカソンもあって、こっちは学生じゃなくても参加可
  • 協賛企業に弊社の名前が出てた。知らんかった。。。

福井 厚さんのLT

  • 35歳定年説?コードが書ければ定年じゃない。