Strategien, Taktiken und Muster der Legacy-Ablösung
![日経電子版を支える基盤API](https://cdn-ak-scissors.b.st-hatena.com/image/square/2819c7021db85df220bd93bb6cf548ca07f2d0bc/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F18ff40c1cdc44b348aeb7583e099ed6d%2Fslide_0.jpg%3F7503896)
Strategien, Taktiken und Muster der Legacy-Ablösung
機能は「カンバン」のみ Trello は有名なトヨタの「カンバン」方式を利用できるウェブアプリです。 タスク管理として、有名な「JIRA」に似た機能を無償プランで使えるという面もあり、利用されている方も多いと思います。 「カンバン」の他に、Slackなどの他サービスと連携できたり、アドオンで機能強化したり、期限を決めたり、ボードを他ユーザと共有することができます。 自分的には「カンバン」さえ使えればよかったので、このアプリで利用できるのは「カンバン」だけです。 必要があれば、個々に好きなものを入れられるよう、基本となるものを作ったつもりです。 そのため、ライセンスは MIT にしてあります。ご自由にお使い下さい。 GitHub https://github.com/mikiakira/php-simple-kanban 使っているもの PHP 5.6+ (PDO is required)
2016年になってから色んなソフトウェアエンジニアの人と話してきて、その中で3人から聞いた例え話、格言、小噺が面白かったので、僕の中だけで留めておかずに開放しておく。 息継ぎをするには『まず息を吐く』という例え話 水泳で息継ぎをするなら『まず息を吐きなさい』と教わるらしい。これは息を吐かずにどこかで息を貯めてしまうと、ちゃんと息を吸えないという事を意味してる。息を吐くと苦しくなって顔は絶対に水面に出る。 これと同じことがソフトウェアの学習にも言える。 つまりまずアウトプットする、なんでも良い。作ったものをGitHubに公開するとか、発表するとか、ブログやQiitaに書くとか。ちゃんとアウトプットしたものはフィードバックがあり、そのフィードバックを受ける(PRやissue, 質問, マサカリ etc)、どんどん吐き出していくと吸わないとネタがなくなるので、吸い込むためにまたインプットする。
こんにちは!Drivemode, Inc. のエンジニアのKAKKAです。本名は平田将久というので、ごくまれに平田さんと呼ばれることもあります。前回までは弊社横幕がブログポストを行っていましたが、今回から私も執筆させていただきます。テーマは表題の通り、実際にDrivemodeは(組織的に)どう動いているの?というお話です。 我々Drivemodeはまだ人数の少ないスタートアップで、ファウンダー含めて全員で8人のチームですが、東京とシリコンバレーのSan Joseに分かれて一つのチームとして日々働いています。「なんでやねん」というツッコミが一秒に3回くらい聞こえてきそうですが、理由としては同じ場所に全員いる必要があるかという問いの答えがNoだったというだけの話です。弊社CEO古賀のインタビュー記事にもあるよう、 僕よりすごくないと採用できない 本当に優秀な人を採用するのはシリコンバレーでも難
今日の夜、トレタの増井さん(@masuidrive)さんと会って晩御飯を食べました。下らない話や日本企業の海外進出の話などをする中で、B2Bサービスがカスタマイズを受け入れるというのがどういうことなのか、という話が大変面白かったので、許可を得た上でブログ記事にさせてもらいました。 B2Bとは、Business to Businessの略語であり、企業が主に企業に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指す言葉です。対義語がB2C(Business to Consumer)で、企業が主に個人に向かってサービスやプロダクトを提供するタイプのビジネスモデルを指します。B2Bビジネスの場合は契約1口あたりの金額が大きくなる傾向があり、逆にB2Cビジネスは1口あたりの金額はさほど大きくないのが普通です。 自分も昔の会社でB2Bを経験したことがあるのですが、B2Bをやる上で1つ大
弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について本人同意済み。弊社特有の部分は一部省いています。) ああ、なんという長い旅だったろう。この会社で5年間もセキュリティを担当していたよ(諸々の失敗は許してくれ) 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
相変わらず仕事ではデザインやりつつJavaScript書いている。 タスクランナーとしてGrunt.jsを使っていたけれども、使ううちに段々不満がでてきた。遅かったり、記述が冗長になりがちでつらかったので最近になってgulpに乗り換えた。 gulpは良い。タスクは自動的に並列に実行され、かつストリームで処理されるので速いし、タスクの記述もストリームベースの書き方のおかげでGrunt.jsに比べるとだいぶ短くなる。 ただ、そこらにあるgulpをちょっと試しただけの日本語の記事やドキュメントをみてても実際のプロジェクトで使えるレベルまでの知識を得られず学習に一日かかった。 この記事では、gulpをまともに使えるようになるまでに必要な知識を書く。 導入とHelloWorld まずは導入。npmからgulpをインストールする。 $ npm install gulp -g $ gulp -v [gu
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
https://medium.com/p/506a06ae35ea 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 自分は最初に手がける立上げ仕事がほとんどだったので、他人のタスクを引継ぐよりは、次の方にバトンタッチすることが多かったと思います。右も左もわからない状況から始める立上げ仕事は、楽しいけれど、前に進めるだけでそれはそれで大変。なので、引継ぐときは「頑張ったね。」と自分に言ってあげたいというのが本音。とはいえ、引継いだ人が後から見れば、相当アラい仕事ぶりに思えたでしょう。大成功してないプロジェクトについては全て、批判は甘んじて受け入れるべきなのかもしれません。 Shamoon Siddiquiはブログで、安易に前任者の責任にする危険性について語っています。 新しく採用した後任のエンジニアが入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く