タグ

読み物に関するmakky55makky55のブックマーク (114)

  • Ruby on Railsはどのように生まれ、発展してきたのか[前編]。作者DHH氏やコアチームが語る動画「Ruby on Rails: The Documentary」が公開

    「1999年か2000年頃、私は37signalsというWebデザイン企業を経営していました。2人のビジネスパートナーとWebデザインを受注していたのです」(Fried氏) Fried氏は業とは別に再度プロジェクトとしてオンライン書籍データベースの開発に取り組んでいました。開発はPHPで行っていたものの、Fried氏はプログラミングでつまづきます。 当時はまだStackOverflowのような技術的な質問に答えてくれる掲示板などなかった時代。Fried氏はブログに「誰かこの問題を解決する方法をご存じですか?」と書き込みます。 するとデンマークからメールが届きます。メールを書いてきたのがDHH氏でした。 「私は(37signals社の)Signal vs. Noiseというブログを以前から熱心にフォローしていました」とDHH氏。 「ブログで彼の質問を見て、私は『おお、この答えを知っているぞ

    Ruby on Railsはどのように生まれ、発展してきたのか[前編]。作者DHH氏やコアチームが語る動画「Ruby on Rails: The Documentary」が公開
  • ソフトウェアエンジニアをしていて影響を受けた5冊(+α)

    他の方の記事ですが、読んでいておもしろかったです。記事に出ているはClean ArchitectureとTDD、LeanとDevOpsの科学くらいしか読んだことなかったです。 また自分も書くことで、他の方も記事を書くようになり、ついでに他の方の記事を読んでみるなどしたいなと思ったので書いてみます。 私はソフトウェアエンジニアとしてのキャリアはまだ7年くらい[1]なので短い方ですが、約7年間の中で読んで印象に残ったものを紹介します。 計算機プログラムの構造と解釈 Scala関数型デザイン&プログラミング Effective Java Programming Rust 実践ドメイン駆動設計 なお、この記事ならびにのリストは誰かの役に立つことは想定しておらず、単に自分が読んで影響を受けているなあと感じるをまとめています。つまり自己満足です。 加えてこの手の記事を書く際には、一応筆者のプロフ

    ソフトウェアエンジニアをしていて影響を受けた5冊(+α)
  • エンジニアとして今の自分を形成した本を5冊紹介する - パンダのプログラミングブログ

    パンダとおくだが、Web業界の当たり前を「これって当にそうだっけ?」と問い直すラジオを配信しています エンジニアとして今の自分を形成した5冊 エンジニアとして働くにあたって自分が大きく影響を受けたを考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。 Clean Coder(クリーンコーダー) Team Geek Clean Architecture(クリーンアーキテクチャ) テスト駆動開発 LeanとDevOpsの科学 この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している(かつての自分がそうだった)。 特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験があ

    エンジニアとして今の自分を形成した本を5冊紹介する - パンダのプログラミングブログ
  • Nintendo Switchの100円セールは『グーニャファイター』に何をもたらしたのか? 販売元MUTANが語る、知ってもらうことの難しさ - AUTOMATON

    Nintendo Switchの100円セールは『グーニャファイター』に何をもたらしたのか? 販売元MUTANが語る、知ってもらうことの難しさ - AUTOMATON
  • 上場記念ポエム

    自分の勤務する会社が今年IPO(株式上場)した。 この記事は上場当日に自分が社内ブログに投稿した記事を編集したものである。 なぜそれをこうして公開する気になったかと言うと、もしかしたらこれからIPOを経験する人の参考になるかもしれない、というのは理由のひとつだ。 もっと大きな別の理由は、この記事には自分が以前に勤めていた会社のことが書いてあるのだが、昨日の忘年会で会った当時の同僚たちに読ませたところ「懐かしすぎてもだえ死ぬ」という好評価をいただいたので、もう少し広く仲間内で盛り上がるためである。 そして何より、年末の休暇にすることもなく暇だった。 自分について40代男性。ITエンジニア。現職は6年目で古参の部類。 マネージャーではあるが、それほどエラい立場ではない。 ちなみに3年近く前のこの記事の投稿主でもある。 中学受験体験記 https://anond.hatelabo.jp/201

    上場記念ポエム
    makky55makky55
    makky55makky55 2019/12/30
    どこかははてブのコメント参照らしい
  • x.com

    x.com
    makky55makky55
    makky55makky55 2017/04/18
    "...行動はボトムアップで..." 最近どんどん腰が重くなっちゃったなぁ・・・
  • システムエンジニアのカレンダー | Advent Calendar 2016 - Qiita

    SIerSIerによるSIerのためのアドベントカレンダーです。 SIの現場でよくある課題・デザインパターンについて書きましょう。 今年は世界中のシステムエンジニアのみなさんで、カレンダーを完成させたいのでよろしくお願いします!! ランキング好調につき、Qiita記事として書いていただけると、より多くの方に見ていただけるようになるので、よろしくお願いします。 昨年のヤツはこちら

    システムエンジニアのカレンダー | Advent Calendar 2016 - Qiita
    makky55makky55
    makky55makky55 2016/12/26
    勉強になることがいっぱい書いてある。SIerであってもなくてもみんな読んだ方がいい
  • SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ

    Slackを入れるとSIerはどうなるのか?」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか? だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と

    SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ
    makky55makky55
    makky55makky55 2016/11/30
    うちの会社でも一時期メンターをしていただいた小野さんの記事。やべえ、SIerもどるか。
  • プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話

    ブログryuzeeによるブログ記事。不定期更新HomeブログプロダクトバックログアイテムはReadyなものだけスプリントに投入す⋯⋯ みなさんこんにちは。@ryuzeeです。 プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。 プロダクトバックログでよく起こる問題プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。 単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。 選択したプロダクトバックログアイテムの中身に対してプロダクトオーナーと開発チームの理解が違ってしまうそのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必

    プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話
  • 「バイバイ」笑顔の幼子、母は橋から落とした:朝日新聞

    ■小さないのち 奪われる未来 子どもへの虐待が後を絶たない背景の一つに「育児の孤立化」があるとされる。ある母子の悲劇を追った。

    「バイバイ」笑顔の幼子、母は橋から落とした:朝日新聞
    makky55makky55
    makky55makky55 2016/11/02
    悲しい。育児は親も余裕(精神的にも時間的にも)を持たないとほんとにいけないと思っている。いらいらしているとぞんざいに扱ってしまうし
  • イケてる環境のWEB系の労働生産性がイケてないSIerのたった三割しかない件 - プロマネブログ

    久しぶりの更新。一度ブログ書くの面倒になると、とことん書くのが面倒になるもんで。 【Web系最高って言うけど当なの?】SIから転職したエンジニア達に聞いてみた - paiza開発日誌 まあ、いつものPaizaのWebアゲSIer Disの記事なわけなんですが。。。 最近、どうでもよくなって放置していたものの、いろいろ誤認している人が増えていそうなので、改めて問題点指摘しておきますか。ブコメ見るとSIer側の反論も欲しそうだし。 とはいえ、開発環境の話はわきに置いて、別の観点を中心とした内容となります。 イケてる環境のWEB系の労働生産性は、イケてないSIerのたった三割 http://www.soumu.go.jp/johotsusintokei/linkdata/ict_keizai_h28.pdf 上記は総務省が毎年公開している「ICT の経済分析に関する調査 」の資料です。 大体1

    イケてる環境のWEB系の労働生産性がイケてないSIerのたった三割しかない件 - プロマネブログ
  • 知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)

    週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを

    知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)
  • 新卒の子にどこまで勉強すれば良いですかね?と聞かれた件 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ちょっと、簡単に答えられなかったので、休み中にまとめました。 「どこまで勉強すれば良いか?」 という質問には、 自分の立ち位置や、今後の目標など関わるので、 それらを踏まえて考える必要があると思います。 職種によっても違いますが、質問された時の状況は、 Web系エンジニアが新卒の子に聞かれた形なので、 考慮いただきたいです。 また、そもそも、どんな背景をもったやつが書いてるんだ?と思う方も いらっしゃるかと思いましたので、簡単に自己紹介してから書きます。 書いている人の自己紹介 現在33歳で、エンジニアスタートしたのが、 2005年08

    新卒の子にどこまで勉強すれば良いですかね?と聞かれた件 - Qiita
  • ふと思いついて書いた。後悔はしていない。 - yamasaのネタ帳

    昨日、マルチスレッドなプログラムのコードを読んでたんです。マルチスレッド。 そしたらなんかロックがめちゃくちゃ競合しててパフォーマンスが出ないんです。 で、変更履歴よく見たらなんか全メソッドを一つのmutexでロックして、マルチスレッドに対応した、とか書いてあるんです。 もうね、アホかと。馬鹿かと。 お前らな、単一mutexで囲うだけの対応如きでマルチスレッド対応とか言ってんじゃねーよ、ボケが。 単一mutexだよ、単一mutex。 なんかthreadを作りまくってる箇所もあるし。多重ループの内側でthread生成か。おめでてーな。 よーしデータを細分化してガンガン別スレッドで処理しちゃうぞー、とかやってるの。もう見てらんない。 お前らな、Fork/Joinフレームワークのスレッドプール実装やるからそれ使えと。 マルチスレッドってのはな、もっと殺伐としてるべきなんだよ。 Work-stea

    ふと思いついて書いた。後悔はしていない。 - yamasaのネタ帳
  • オブジェクト指向の欠点をカバーする努力 - Qiita

    オブジェクト指向の問題点 インターネッツを良くするポエムというのは、「こういう問題に対して、こういうソリューションでカバーしてきたよ」をみんなでシェアすることだと思うので、ここに挙げられていることの一部に対して、オブジェクト指向界隈が今までこんな工夫をしてきたよとか、僕の目から見えている「技術発展の流れ」について書いてみようと思います。まあ僕も全ジャンルをまんべんなくやっているわけじゃないし、一部想像で補っている部分もあります。他にもあればぜひシェアしてください! 上記のサイトで書かれている内容のうち、 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 関係性が表現できない ユーザレベルでの部品化再利用に全然なっていない について取り扱います。 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 元は2項目ですが、内容的

    オブジェクト指向の欠点をカバーする努力 - Qiita
  • 自分の仲間を探すなら能力や性格よりも、自分と同じだけコストを払ってくれる人を選んだ方がいいという話 - 僕のYak Shavingは終わらない

    元後輩?から「どんな人を創業メンバーに選ぶべきですか?」質問をされたので、自分なりの回答をした。 正直今の会社の創業メンバーは、前職同期である社長の素晴らしすぎる人脈もあって、奇跡的な能力のゴールデンバランスと性格的相性の良さを兼ね備えた6人が手を上げ起業している。 なので、このこと自体は全然参考にならないよという前置きをおいたあとに、自分なりに思ったことを述べた。 コストを払わない人と一緒にやるとチームが自然解散する 起業前によくあったのは、エンジニア1人+企画2人とかのパターン。 大抵が職がある状態でのプライベートプロジェクトで、土日のどちらかで1, 2週に一回集まって企画を考えてプロダクトに落として行くということをやっていた。 で、よくあるのが企画中はみんなでかなり盛り上がって笑い合って、じゃあこれで行こう!絶対いける!みたいになるんだけど、はいじゃあ実装開始ってなるとエンジニア

    自分の仲間を探すなら能力や性格よりも、自分と同じだけコストを払ってくれる人を選んだ方がいいという話 - 僕のYak Shavingは終わらない
  • 倒産した技術系スタートアップ企業から学ぶ7つの教訓 | POSTD

    多くのGoogle社員と同様、私は起業したくてたまりませんでした。Googleで働くのは名誉なことで、大きなメリットがありましたが、”これ”という決定的な何かが欠けていたのです。 私たちの多くは”あの偉業”を成し遂げた”あの人物”と呼ばれたいと思っていますが、既に定評のあるテクノロジ大企業で、そういった人物になるのは不可能です。 その原動力がどこから来るのかは誰にも分かりませんが、私は多くの人々が自分と同じ気持ちを抱いていることを知っています。私はその欲求を満たすために、会社を設立せざるを得なかったのです。 スタートアップでは資産のほとんどは経営陣が持っていて従業員は持ち分が少なすぎると書かれた文章を読んで、がくぜんとしました。それで自分の会社を設立する決心をしたのです。まず、共同創業者と私は、2012年2月頃に仕事を辞めました。私たちには大した計画はありませんでした。取り組もうとしている

    倒産した技術系スタートアップ企業から学ぶ7つの教訓 | POSTD
  • 「ノー残業会社」への道のり

    ある会社で対立があった。内容は、「残業を減らす」というものだった。 「今月から、残業を減らす活動を行います。1日の残業時間は2時間以内にとどめていただき、月の残業時間も25時間以内にして下さい。」 と総務部長が言う。 社員たちは突然の通知に困惑の表情を浮かべた。 ……そんなこと、できるのか? 今の業務量で、残業をやめるとお客さんに迷惑がかかるのでは……? ……仕事が多すぎて、終わらないんですけど。 部長が言う。 「ご協力、お願いします。」 そこで一人の人物が手をあげた。そこそこできる、中堅のYさんだ。 「部長、今の業務量だと、先ほどの目標値をクリアするのはかなり難しいかと思いますが、何か施策でもあるのですか?」 おおお、Yさん、よくぞ言ってくれた。そうだよ、そうだよ、と、皆こころの中で思う。 「勿論だ。一番有効な方法は電源をきることだ。だから、午後8時になったら、うちの会社はすべての電源を

    「ノー残業会社」への道のり
    makky55makky55
    makky55makky55 2016/03/24
    読んでいて、最初の想像より違う展開になった。へー。
  • エンジニアのモチベーションを下げる方法 - jfluteの日記

    モチベーションの高いエンジニア... ガンガン働いてくれそうで、放っておいても安心でしょうか? 安心してください。 簡単に下げられますよっ! o 序の口: ディスプレイを小さくする o 序二段: 毎日スーツを着させる o 三段目: 椅子を固くして、机を狭くする o 幕下: 簡単に作れるでしょ?って上から目線で言う o 十両: 打ち合わせ一杯で連続した集中時間を与えない o 前頭: 情報共有しづらい、風通しの悪い現場に o 小結: 引き継ぎなしで人をどんどん入れ替える o 関脇: 背景わきまえず、コード汚い、仕組みひどいと言う o 大関: 仕事を突然終了させて無意味感を与える o 横綱: 質的でないことに時間を取らせる仕組み 序の口: ディスプレイを小さくする エンジニア仕事の多くはパソコンの中にあります。そのパソコンの中を覗く唯一の手段はディスプレイです。そんな狭い中で、色々な資料をみ

    エンジニアのモチベーションを下げる方法 - jfluteの日記
  • 家事育児を「やっているつもり」の旦那へ見せた執念の分担図 | ママスタセレクト

    そろそろ4月入園の保育園の承諾通知が届くころですね。育児休業中のママたちは、職場復帰の準備を整えているのではないでしょうか。そんなママのもっとも大きな課題は「育児・家事・仕事」をどうやって回していくかということ。そのために必要なのが、なんといってもまずは旦那の協力です。育児休業中はママの方がどうしても時間的余裕があるので、家事育児の負担は大きくママに偏りがちです。復帰を目前にして「どうやって分担を求めようか」とあせっている人も多いのでは?4年前の私もまさにそんな状況でした。そして、「復帰すれば旦那も変わるだろう」と思って仕事復帰をしたのです。 それが甘かった…。 仕事復帰しても旦那は変わらない 復帰して半年、旦那は一向に変わりませんでした。なぜ私ばかりが16時に仕事を終えて、周囲に肩身の狭い思いをしながら帰り、ダッシュで子どもをお迎えに行って、ボロボロこぼされたりしながらご飯をべさせ、お

    家事育児を「やっているつもり」の旦那へ見せた執念の分担図 | ママスタセレクト