タグ

2015年10月25日のブックマーク (7件)

  • プロダクトマネージャー制度を導入するにはどうすれば良いのか - 小さなごちそう

    KAIZEN platform Inc. 技術顧問 伊藤直也さんの、プロダクトマネージャーに関するツイートがとても示唆に富んでいるのでまとめさせていただく。 ソフトウェアエンジニアのひとがなにかと口うるさいの、組織的な怠慢のツケをはらう羽目になるのがだいたい自分たちだから、というのはあるだろうね。ごまかしがきかない仕事だし — Naoya Ito (@naoya_ito) 2015, 10月 21 良く見る典型例は、企画とか品質を保証する仕事までエンジニアに丸投げして、エンジニア側にはその期待値がなくてお互いの思惑がずれる、みたいなケースだな。この場合にエンジニアがしょぼいものを作るから、と指を指されてるけど、問題は製品企画開発の責務を組織の中で曖昧にしてるところにある — Naoya Ito (@naoya_ito) 2015, 10月 21 たまたまエンジニアの中にそこまで含めて上手な

    プロダクトマネージャー制度を導入するにはどうすれば良いのか - 小さなごちそう
    dev0000_1
    dev0000_1 2015/10/25
    その為のコストを経営陣にどうやって納得させるのかが最大の課題かと。
  • アプリ甲子園2024【中高生のためのアプリ・Webサービス開発コンテスト】

    「アプリ甲子園」は、次世代を担う若手クリエーターの発掘と健全な育成支援を目的として、2011年より開催しているアプリ・Webサービスの開発コンテストです。毎年、未来のスターが大会から生まれています。

    アプリ甲子園2024【中高生のためのアプリ・Webサービス開発コンテスト】
  • OATHによるワンタイムパスワードの仕様 - 3

    前回は2つのワンタイムパスワードの生成方法について取り上げました。今回はいよいよ実際の生成アルゴリズムを取り上げましょう。TOTPをベースに説明します(ただ、前回も解説したように、基的なロジックはTOTPとHOTPで同じです)。 参考としてpythonのコードも併記してみます。 1. タイムステップを考慮したカウンタの算出TOTPの場合、カウンタはunixtimeになります。しかし、これをそのまま使うとワンタイムパスワードが毎秒変わってしまうことになり、さすがにこれは実用的ではありません。それで、ワンタイムパスワードが切り替わる間隔としてタイムステップ (Time-Step) を設定し、unixtimeをタイムステップで割った値をカウンタとします。 messagetime = unixtime / timestep これにより、タイムステップが30なら、30秒間は同じワンタイムパスワード

    OATHによるワンタイムパスワードの仕様 - 3
  • クラウド 機能・サービス(MQTT) | ニフクラ

  • 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログ

    独学でプログラミングを勉強してIT業界に就職したけど、やはり独学で得た技術だけだと通用しないと思う局面が幾たびもあった。 今ははたくさん出てるし、動画もあるし、生のコードを読みたければGitでいくらでも読めるし、独学で勉強する土台はかなりできていると思う。 それでもなかなか実務に通用しない。 その理由はいろいろあるんだけど、自分が強く感じた3つの理由をこの記事では挙げたい。 1.独学では妥協をいくらでもできる 独学で作っているプログラムだと、使い勝手が悪い機能を見つけたとしても「ま、ええか」で済ませてられてしまう。 誰に命令されて作っているわけでもないから。極端な話、バグがあっても放置できる。「小さいバグだしいいでしょ」と。実務でそれをやったら殺される。 「ま、めんどくさそうだしこれでええか」で済ませてしまうと、めんどくさい実装をすることで得られる技術の向上がなくなる。 実際、現場だと仕

    独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログ
    dev0000_1
    dev0000_1 2015/10/25
    まぁ、実務においても、ある現場で覚えたことが別の現場ではむしろ悪癖になるってのもあるわけで。
  • 既存のコードを参考にして新規にコードを書く事の光と闇 - 文系プログラマによるTIPSブログ

    恐らくこれは開発現場であるあるな出来事だと思います。 今回のお題は「既存コードを参考にして新規コード書く」事についてです。 あなたが部下または外部の方に作業依頼をする時、どんな風にコードを書いたらいいかを事前に説明しますね。その時「この辺に書いてある既存のコードを参考に書いて下さい」と言ったりしますよね。 もしくは特に書き方の方針を伝えない場合は、依頼された側が「既存のこの辺のコードを参考に書きます、書きました」と言ったりします。 「参考」とは この言葉のポイントは「参考」という部分にあります。実はこの「参考」には光と闇が潜んでいるのです。 何故ならこの「参考」は、大抵の場合は「ほぼコピペ」を意味しているからです。 ☓ 「既存のコードを参考にする」 ◯ 「既存のコードをコピペする」 「ほぼ」と言っているのは、数カ所違うだけのコピペの場合が多々あるためです。 ほぼコピペのメリット 周りのコー

    既存のコードを参考にして新規にコードを書く事の光と闇 - 文系プログラマによるTIPSブログ
    dev0000_1
    dev0000_1 2015/10/25
    コピペ云々が問題ではなくて、保守フェーズにまともなアーキテクトがいない、という問題のような。
  • IT業界でありがちな説明下手について - 文系プログラマによるTIPSブログ

    横着しちゃいかんのです。 IT業界に限った話しではありませんが、説明下手な人っていますよね。 私がIT業界でよく日頃から感じている説明下手(質問下手とも言う)なエピソードについて書いてみます。 例 この話から私が理解できた部分 この話から私が理解できなかった部分 どうして話が伝わらないか どうすれば伝わったか こういう質問が返ってきたら説明下手かも!? 雑感 例 やらないおさん、落ちちゃうんですけど、getHoge()のこの部分があれで、多分ああなんじゃないかと思うんですけど、どうすればいいですか? ???? え?ごめん。何の話?いきなりソースコードの具体的な箇所の話されても理解できないから、落ち着いて順を追って話してみようか ※ 以降、質問をする側を「やるお」、される側(私)を「やらないお」とします。 ※ getHoge() メソッドはやるおが自分で作った独自メソッド。当然やらないおは知

    IT業界でありがちな説明下手について - 文系プログラマによるTIPSブログ
    dev0000_1
    dev0000_1 2015/10/25
    「状況を整理する手間暇」をどちらが行うか、という点で、力関係の問題のような。