by shigemk2

当面は技術的なことしか書かない

DB設計の流れ

PC全般
  1. エンティティの抽出
  2. エンティティの定義
  3. 正規化
  4. ER図の作成

実体をテーブルに落とし込む

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

POA/DOA

PC全般
  • データ中心アプローチ(データ設計から始める方法)
  • プロセス中心アプローチ(プロセス設計から始める方法)

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

applyMiddleware

React

applyMiddlewareを使うことでdispatch関数をラップし、actionがreducerに到達する前にmiddlewareがキャッチできるようにする

applyMiddleware · Redux

qiita.com

import { createStore, applyMiddleware } from 'redux'
import todos from './reducers'

function logger({ getState }) {
  return (next) => (action) => {
    console.log('will dispatch', action)

    // Call the next dispatch method in the middleware chain.
    let returnValue = next(action)

    console.log('state after dispatch', getState())

    // This will likely be the action itself, unless
    // a middleware further in chain changed it.
    return returnValue
  }
}

let store = createStore(
  todos,
  [ 'Use Redux' ],
  applyMiddleware(logger)
)

store.dispatch({
  type: 'ADD_TODO',
  text: 'Understand the middleware'
})
// (These lines will be logged by the middleware:)
// will dispatch: { type: 'ADD_TODO', text: 'Understand the middleware' }
// state after dispatch: [ 'Use Redux', 'Understand the middleware' ]

webサービスの企画と設計 メモ

開発
  • コンテンツ企画
  • ターゲットユーザーの明確化
  • サイトマップ作成
  • ワイヤーフレーム作絵師
  • ペーパープロトタイプ
  • 画面遷移図の作成

  • 要件定義

  • エクセルとかでディレクトリマップを作っておく

  • cacooでワイヤーフレームとか画面遷移図は作れる
  • prottとかでペーパープロトタイプは作れる

絵で見てわかるWebアプリ開発の仕組み

絵で見てわかるWebアプリ開発の仕組み

  • 作者: 松村慎,大久保洋介,武田智道,清水紘己,扇克至,里吉洋一,本末英樹
  • 出版社/メーカー: 翔泳社
  • 発売日: 2015/08/18
  • メディア: 単行本（ソフトカバー）
  • この商品を含むブログを見る

DB設計

DB設計の順番

  • 入出力データの抽出
  • 永続化データの抽出
  • テーブル設計(ER図)

ちょいちょいtypoがあるけど

絵で見てわかるWebアプリ開発の仕組み

絵で見てわかるWebアプリ開発の仕組み

  • 作者: 松村慎,大久保洋介,武田智道,清水紘己,扇克至,里吉洋一,本末英樹
  • 出版社/メーカー: 翔泳社
  • 発売日: 2015/08/18
  • メディア: 単行本（ソフトカバー）
  • この商品を含むブログを見る

独学でITエンジニアになって生きていくために自分がやったこと

まとめ

男子中高生がなりたい職業No1がITエンジニアというちょっとした僥倖を目にした。自分は大学で情報科学などは勉強していない。プログラミングを始めたのは大学を卒業してからである。 プログラミングを初めて7年。職業としてITエンジニアを初めて6年になる。普通に生きてる。たぶん普通に。職業プログラマーとして生き続けるためにやったことを適当に書き連ねていく。 自分はスーパーエンジニアではない。実家のスネカジリで生きていた人間だ。そういう人間が普通に独り立ちするためのちょっとした備忘録である。

生存バイアスが全面に出ているが、ご了承いただきたい。

写経

「Ruby入門」みたいな本でも、フレームワーク(play frameworkとか、reduxとか)の公式サンプルでも、AWSのチュートリアルでもなんでもいいが、とにかくなぞって、いじって、どうやって動いているかを確認すること。数をこなすことが重要だと思う。一つ一つの質がヘボくても、それが数千数万なら力になる。

ソースコードやドキュメントが間違っていたら、フィードバックを出せばいい。本や製品なら問い合わせフォームがあるし、OSSならcontributing xxxでググるとフィードバックする方法が記載されている。

ブログ

http://www.shigemk2.com ブログはたぶん6年くらい毎日書いている。ブログを始めたのは上司に言われたからである。毎日書けとは言われていないが、気づいたら毎日やっていた。毎日やらないとカンが鈍る気がしたので、なぐり書きのメモでもなんでもいいから言語化することで理解を深めるために続けている。数をこなすことが重要であるという信念のもと、ずっと続けていると思う。数千、数万の知識が、自分の身を助けると思う。

本を読む

技術書がメインだけど、読める本は片っ端から読んだ。媒体は紙でもいいし、電子書籍でもいい。とにかく数をこなそう。読書で得られたことは、やっぱりブログに書いてメモするといいと思う。GitHubにサマリーを上げてもいい。読むだけじゃなくて、メモは最低限どこかに残しておくと良い。

勉強会への参加と発表

これはそんなに頻繁じゃなくていいと思う。他人のノウハウは刺激になる。僕は頭が悪いので部屋にこもって自分の頭だけで考えると考え方や行動に歪みが出ておかしなことになる。具体的にアドバイスをくれるメンターがいればいいが、自分に向けたアドバイスじゃないものでも参考になるものは多い。可能であるなら、発表もしてみるといいと思う。セルフブランディングは非常に重要だ。発表をすることで自分の知見を再確認して人にわかりやすく伝えることができるチャンスであるし、そこから他のエンジニアとのコミュニケーションが生まれる。自分から話しかけに行くのは極度に苦手だ。でも話しかけに来る人にたいして、ほんのちょっとでいい。ほんのちょっとでいいから、勇気をだして話しかけたり飯に誘ったりするといいと思うんだよ。

最低限のコミュニケーション

友達は多くなくてもいい。選ぶ必要もない。でも、話しかけに来た人だけでもいいから、縁は大切にすること。僕の場合、首の皮一枚で残っていた友人がたまたま起業しており、誘われたので丁稚のエンジニアとしてキャリアを始めた。今の会社も、たまたま勉強会で発表していたところを別のエンジニアの参加者にリクルートされて入社している。重ねて言うが色んな人と付き合いを重ねる必要はない。でも、最低限でいいから誰かとつながりを持っていることは重要だと思う。スキルのない人間がエンジニアとして働くためには、独学では限度があるので、最低限どこかの会社に籍を置いて仕事するといいと思っている。

以上。雑に書いた。自分と同じような境遇の人間がいて、この文章を読んでくれれば幸いである。