パラノイアのプログラマと第６感 - megamouthの葬列
今だから白状すると、昔、運営していたサービスの一般ユーザーのパスワードをハッシュ化（暗号化）せずに平文でDBに保存していたことがある。 言いわけは、幾つかある。 一つは、今では当たり前のようについているパスワードリマインダーの仕組みが当時は一般的ではなかったこと。 ユーザーがパスワードを忘れた、と問い合わせしてきた時に、最も自然な方法はまさに当人が設定した「パスワード」を一言一句違わず登録メールアドレスに送信することだった。あなたのパスワードは○○○です。ああそうそう、そうだったね。こういう感じだ。 当時のユーザーはそれを不審がらなかった。 またサポートコストの問題があった、パスワードの再発行を、そのためのトークンを含んだ長いURLを、大半のユーザーが嫌がっていた。 サポート部門はOutlookExpressに表示された長すぎるURLのリンクが途中で切れててクリックできない、という苦情にい
6 年間の起業を終えて - IT戦記
スマートニュースの社員になりました 皆様、お久しぶりです！約 7 年振りにこのブログを書いています。 元気にしてましたか？僕は元気です。 実はこの 6 年間 id:mizzusano とカクテル株式会社という会社をやっておりまして、先日のプレスリリースにもあったようにこの度会社ごとスマートニュースにジョインすることになりました。 UUUM に遊びに（？）行ってはしゃぐ僕と id:mizzusano そこで今日は振り返りも兼ねて、以下の 3 点について、この 6 年間考えていたことを書いて見たいと思います。 事業アイデアより大切なこと 起業家が健康的に働く方法 プログラマーが起業するということ 少しでもこれから起業したい人のお役に立てればと思っております。 事業アイデアより大切なこと 6 年間の事業を振り返えると失敗の連続でした。その中で、事業そのもののアイデアより共に起業するメンバーが大切
ドイツの受託開発会社を退職しました - WETな備忘録
2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日本に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い
なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
消えたプログラマの残したものは - megamouthの葬列
システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の本人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい
ドイツでプログラマとして働いて半年がたちました。 - WETな備忘録
と、いうやつを8月末に書こうと思ってたらもう12月がすぐそこまで来ている。 人生設計とか考えるのがしゃらくさくなり、と言えば格好はいいんですが、何か僕の将来に対する唯ぼんやりした不安と向き合うことに疲れて、ビールとソーセージが好きだという理由だけでドイツに行きたい、というか行くことに決めたのが昨年の11月くらい*1で、そのときは前も後ろも何も決まってない状態だったので、いそいで準備とかしたのでいろんな人に迷惑をかけてしまったかなあと思いつつ、深く感謝はせども、反省はしていません。いつも本当にありがとう。 こういう無茶な生き方をするために心技体マッチョなものを身につけたはずなのであって、せっかくなので無茶な生き方しないともったいない。 所詮地球でした ドイツに来て即、ボーフムというサッカーしか無えみたいな田舎街に単身で顧客に常駐して、スイスのクライアントの2次請けみたいなことをしたんですが、
Webプログラマと数学の接点、その入り口
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)
週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを
何かを極めるということ。 - chokudaiのブログ
この記事は、社長としてではなく、競技プログラミングの１選手としての記事になります。あんまり初心者への配慮とかしてません。 おそらく多くの人は、実践的に使えるアルゴリズムとかの記事を望んでるんだと思うんだけど、僕はどちらかというと、精神論のほうが得意なので。 近頃、本当に弱くなったなぁ、と感じることが多い。 いや、周りが強くなったのかもしれない。昔判らなかった問題でも、今なら解ける。そういう問題は多い。それを考えると、昔よりは強くなっているが、相対的に弱くなっているだけかもしれない。 そりゃまぁ、RedCoder（Rating2200以上。日本で30人程度の水準）を保つ程度なら出来る。確かにRedCoder手前に壁はある。だが、まともにコンテストに取り組んで、解けなかった問題をすべて復習する、それを数年間続けてれば、ある程度のセンスがあれば辿り着ける領域だ。さすがにそこから滑り落ちることはな
3人のプログラマの話 - A Memorandum
あるIT部門で一人の男が難しい顔をしてPCに向かっていた。 「あなたはここでいったい何をしているのですか？」 「何って、プログラミングに決まっているだろ。朝から晩まで、設計書の内容を間違わずにコードに落とさなきゃいけないのさ。あんたにはわからないだろうけど、目は疲れるし腰は痛くなるし」 男は腰を叩き、首をぐるりと回し、ため息をついた後、再びキーボードを叩きだした。 別のフロアでも同じようにPCに向かっている男がいた。 しかし先ほどの男のように辛そうには見えなかった。 「あなたはここでいったい何をしているのですか？」 「俺はね、入金処理のプログラムを書いているんだ。一旦出来上がったんだけど、この部分がもう少し綺麗に書けないかなと思ってね。修正してるんだ」 「大変ですね」 「まあ、これが仕事だしね。」 そう言って男は設計書を持って隣の男と話始めた。 また別のフロアでも同じようにPCに向かってい
新人プログラマ向け・スキル向上のための具体的なアプローチと考え方 - give IT a try
はじめに：「僕にもそんな頃があった」 先日、西脇.rb＆神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。 この勉強会は出題者（＝僕）が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。 参加者の方の中には最近プログラミングを始めた、という人も何人かいました。 そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。 また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか？」みたいな質問を受けたりもしました。 その中で言われたのが、 「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」 「えっ、そんな短い時間で作れるんですか」 といったようなコメントです。 そういったコメントを聞くと、「あー、僕にも
30日間で300回のプログラミング面接をしてわかったこと | POSTD
プログラマの採用方法を改善するため、1カ月程前にTriplebyteを立ち上げました。昔から変わらず、履歴書、コードをホワイトボードに書かせるプログラミングテスト、そして直感など、これらを判断基準に面接を行う企業が多すぎます。私たちは、より良い採用方法について最初に考えたアイディアを マニフェスト に記しました。それから1カ月と少しが経過し、この30日間で、300回の面接を行いました。私たちはアイディアを実行に移し、どの方法が有効で、どの方法が有効ではないかを確認し、そのプロセスを繰り返すということを始めたのです。この投稿には、300回の面接を通して私たちが学んだことを書いていこうと思います。 投稿では、細かい内容についての説明が多くなりますが、キーとなる発見は以下の通りです。 私たちが作ったオンラインのプログラミングクイズの結果を見れば、高い確率でプログラミング面接の結果を予測できる。
プログラマのための線形代数再入門
2015/1/30 「プログラマのための数学勉強会」にて発表。 動画: https://www.youtube.com/watch?v=hyzotMaTtPg
新人プログラマに正月休み中を使って読んでみてほしい技術書をセレクトしてみた。 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 今年、書いた幾つかの記事のタネ本であったり、新卒教育の際に参考書籍としてあげたものを中心にリストアップします。一応amazonへのリンクも貼っておきますが、先輩が持ってたりすると思うので、冬休みに借りて一気に読んでおくのもいいかと思います。 その時々、必要な技術の習得に日々追われているんじゃないかと思いますが、いつまでも使
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
三年予測 | 「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。 | dodaエンジニア IT
「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
プログラマーがイラレで絵を描けるようになると、こうなる - ppworks.jp
プログラマー、絵が描けないじゃないですか（偏見） こんなじゃないですか。 なので描けるようになりたいなとずっと思っていて、ベジェ曲線って滑らかでナンカヨサソウ、とチャレンジしました。 「ベジェ曲線」習熟ドリル 7,8年前に買ったのがこれ。そう、チャレンジは2回目なのです。前回は3ページぐらいで挫折してました。んで、最近急に暇になったのをキッカケに「よしやろう」という気になり始めたのです。 改訂二版〈Illustratorで学ぶ〉「ベジェ曲線」習熟ドリル 作者: 中村高之出版社/メーカー: ラピュータ発売日: 2005/04メディア: 単行本購入: 2人 クリック: 8回この商品を含むブログ (4件) を見る (2014.1.10追記) なんと、長らく手に入りにくかったこちらの書籍が新装改訂版で再登場とのこと。 表紙が若干、損していた分、今回はスタイリッシュで内容と合っていてヨサソウです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitBook – Knowledge management for technical teams
https://qiita.com/PLHX/items/c20b953abad3c9e4f95e