2017年3月19日のブックマーク (6件)

  • React+Redux+Express+MongoDBでものすごくシンプルなCRUDアプリをつくる - Qiita

    概要 React+Redux+Express+MongoDBでCRUDアプリを作ります。 この記事の目的は、React/Reduxを触り始めた人が サーバーとの通信の方法(より一般的には非同期処理の方法) Reduxにおけるフォームの扱い ExpressによるAPI node.jsからのMongoDBの操作 Herokuへのデプロイ など、主にサーバー側のデータの操作に関わる基的な事項を学ぶきっかけを作ることです。 この目的に集中するために、それ以外の点については一切気にしないことにします。 そのため、初心者以外の人(上記の内容を理解している人)がこの記事を読んでも得るものはないと思います。 この記事が書かれた背景には、少し前に自分自身がjavascriptによるフロントエンド開発からwebプログラミングを学び始めたころの経験があります。ReactやReduxの基的な文法の理解を終えて

    React+Redux+Express+MongoDBでものすごくシンプルなCRUDアプリをつくる - Qiita
  • プロセスがファイルに読み書きしてる内容を覗き見する - ablog

    確認方法 ファイルディスクリプタ番号を確認して ls -l /proc/<PID>/fd tail で見てみる tail -f /proc/<PID>/fd/21 実行例 $ while :; do date; sleep 5; done > foo.log & [1] 23801 $ ps -elf|egrep [2]3801 1 S oracle 23801 22232 0 76 0 - 16525 wait 11:03 pts/2 00:00:00 -bash 0 S oracle 23813 23801 0 76 0 - 14732 - 11:03 pts/2 00:00:00 sleep 5 $ ls -l /proc/23801/fd total 0 lrwx------ 1 oracle oinstall 64 Mar 20 11:03 0 -> /dev/pts/2 l-w

    プロセスがファイルに読み書きしてる内容を覗き見する - ablog
    wordi
    wordi 2017/03/19
  • 中途社員をスムーズにチームに迎え入れる方法 - 組織を極める

    転職、社会人大学院の修了、中小企業診断士の実務補習と目まぐるしい日々を送っていましたが、なんとか少しずつ落ち着いてきました。新しい環境にも慣れ始め、学位を無事授与いただき、診断士の実務補習も修了証をいただくことができました。そして、診断士の資格取得を契機に、ブログタイトルも変更しました。今後は中小企業診断士の端くれとして、管理部門領域を中心にビジネス全般の情報発信をしていきます。残すタスクはハローワークで教育訓練給付金の還付手続きをするのみです。10万円は大きいですからね。 さて、これまでの人事の仕事柄、新しい方を迎え入れることはあっても、自らが迎え入れられることはなかなか経験しません。今日は自分自身が新しい環境に迎え入れて頂いた際に良かったことを共有させていただきます。 チームビルディング 入社初日に一般的なオリエンテーションに加えて、チームビルディングの機会を頂きました。目的は、チーム

    中途社員をスムーズにチームに迎え入れる方法 - 組織を極める
  • アニメキャラの呼び方

    的に「フルネーム+さん付け」なのだが、これは童貞っぽいとバカにされやすいらしい。 「なんでだよ。好きに呼ばせろよ!」と思っていたが、よく考えたら俺はルパンはルパンと呼ぶしのび太はのび太と呼んでいる。 俺が「フルネームさん付け」で呼ぶのは、アニメの女性キャラに限っているのだと気が付いた。 うーむ、これでは童貞っぽいと馬鹿にされても仕方がない気がしてきた…。 でもなー、ちゃん付けは厳しいな。俺はちゃん付けは、なんかかなり距離感が近過ぎると思うんだ。半径1メートル以内にいる感じがする。 呼び捨ては刺々しさがあるしなー。愛称は逆に恥じらいが無くて、意外といけるんだよな。 こうして考えてみると、確かに童貞っぽいということは否めないが、「フルネーム+さん付け」は敬意の表れでもあるということは念押ししておきたい。別にのび太やルパンに敬意がないわけではないが。 あ、あと「苗字+さん付け」や「名前+さん

    wordi
    wordi 2017/03/19
    ニンジャスレイヤー=サン
  • チームが崩壊しうる要素3つを備忘しておく - インターネットの備忘録

    急ごしらえのタスクフォースチームに入って慌ただしい数週間なのですが、「あっこの要素はまず潰しておかないと、チームって崩壊するんだな」と感じた点があったのでメモします。まだあるかもだけど、とりあえずこの直近でやばいなと思ったこと。 Why?まで落とさず作業を進める 「なぜその仕事をする必要があるのか」「これはなんのための作業か」を全員が理解しないまま目先の作業に取り組むと、成果物にものすごいバラつきが出てしまう。その資料は何を伝えるものなのか、要求した人は何を知りたくて必要としているのか、をしつこく確認するのは重要で、それを全員に徹底しないと、やり直しが大量に発生するし、やり直させることで作業者のモチベーションも下がる。 やり直しも「頼んだことができてない」はまだよくて、「頼んでないのにできてない」が、なるべく少なく済むようにしないといけない。 これは、依頼側もただ作業手順を伝えるだけじゃな

    チームが崩壊しうる要素3つを備忘しておく - インターネットの備忘録
  • カスタマイズをしない

    自分の会社ではパッケージ製品、つまりお客様の環境で動かして頂く製品を販売している。 そのため、カスタマイズを希望される事もある。今の機能では簡単に実現するのが難しいというのがほとんどの希望理由だ。 カスタマイズの定義は製品に対して+アルファの何らかの特別な対応を機能を追加することという事にしておく。 結論から言うと自分の会社では一切のカスタマイズを受けないというスタンスだ。カスタマイズはメリットよりデメリットの方が多いという考え方からだ。 カスタマイズのメリットまちがいなく売り上げを上げやすい事だろう。カスタマイズが必須な場合の顧客はカスタマイズを受け付けない製品を購入しない。 さらにカスタマイズ対応ということで、追加の開発費やサポート費を手にすることができる。これは前職で十分実感できた。 ただメリットはこれしか無い。 カスタマイズのデメリット一番大きいのはコードのフォークが発生してしまう

    wordi
    wordi 2017/03/19