タグ

開発に関するn_knuuのブックマーク (51)

  • 役立つコードレビュー 8つのヒント | POSTD

    役立つコードレビュー(CR)のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ

    役立つコードレビュー 8つのヒント | POSTD
  • 開発者が、開発者ではない同僚から言われて嬉しい11の言葉 – 「クライアントが、IE6で使えなきゃダメだと言っている」 | POSTD

    開発者が、開発者ではない同僚から言われて嬉しい11の言葉 – 「クライアントが、IE6で使えなきゃダメだと言っている」 「 決して、 君にキレそうなのを隠すために笑っているんじゃないよ」 非開発者は、職場の開発者をコードで魔法を生み出す人々だと思っています。開発者なら、終日複雑なAPIインテグレーションを構築することもあれば、マウスをカチカチさせて単にSteamで West of Loathing をプレイしているだけの場合もあるでしょう。99%の同僚にはその違いが分かりません。テック企業は開発チームなくしては文字どおり存在しえないのに、開発者は、日がな無為な会議に出て他人の仕事を自分の手柄にしているチーフ・インスピレーション・ニンジャといった役職の人々よりも給与が低かったりします。 開発チームともっとうまくコミュニケーションをとれる方法はないものかと考えている人に、開発者が非開発者から言

    開発者が、開発者ではない同僚から言われて嬉しい11の言葉 – 「クライアントが、IE6で使えなきゃダメだと言っている」 | POSTD
  • 自社製品の売上で従業員の給与をまかなえるようになった

    目標としていた社員の給与をすべて自社製品の売上でまかなうというのが達成できた。ということで自社製品ほんとうに売れるまでの距離が長いという話をしたい。 前提資金調達は一切していない社外のお手伝いしてお金を稼ぐ資金調達している時点で、そのビジネスに注力できるのでこの話は関係ない。 よくある話そもそも資金調達していないので、完全に社外のお手伝いに依存することになる。社外のお手伝いはいつなくなるかわからない。 社員に給与は払わなければいけないので、役員は自分の給与以上に働く必要がある。忙しくなる。自社製品作ってる暇がなくなる。 結局社外のお手伝いがメインの会社になる。 ここまでがよくある話。 社外の手伝いが忙しい会社ほど自社製品を作りたいという話を良くしている。実際は何もしていない。 自社製品を作るのが難しい誰もが売れる製品を作れるわけではない。売れる製品は正直、運の要素がかなり高いと思っている。

    n_knuu
    n_knuu 2017/07/16
    なれる!SEで読んだ
  • 研究と開発のはざま - でかいチーズをベーグルする

    博士を取ってからの3年間はアカデミックで仕事をしていたけど、4月から民間企業に移ることにした。転職するかどうかそうとう悩んだわけだけど、その時に研究についていろいろと考えたのでちょっと書いてみたい。 工学では研究と開発の違いなんて無い 誰もが納得するような明確な違いは無いと思う。あったら教えて欲しい。 実際、ほとんどの研究(論文)が何かを開発しているし、それが世の中の役に立たないと評価されない。逆に、ほとんどのプロダクトには新規性(もしくは他のプロダクトとの差異)がある。確かに、工学において研究と呼ばれるものは開発と呼ばれるものより平均的には基礎的なことをやっているとは思うけど、とはいえ明確な線引は出来ない。 研究を神格化しすぎる風潮があるんじゃないかな。 「研究者です」というと「すごい!」と言われることがよくある。そう言ってもらえるのは嬉しいけど、べつにすごくないよ。99%の研究者は世の

    研究と開発のはざま - でかいチーズをベーグルする
  • SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ

    ネット上ではSIer批判=技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態

    SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ
    n_knuu
    n_knuu 2017/02/13
    いい話
  • DevOpsとは何か? そのツールと組織文化、アジャイルとの違い

    両氏はこのプレゼンテーションの中で、それぞれの役割の違いから対立することの多い開発者(以下、Dev)と運用者(以下、Ops)の対立構造を次のように示した。 Devの役割が“システムに新しい機能を追加する”である一方、Opsの役割は“システムの安定稼働”である。そのため、Devが新しい機能を追加したくても、Opsはシステムの安定稼働のために変更を加えたがらない、という対立構造が作られてしまっていた。 しかしDevとOpsのそれぞれのミッションは(DevOpsの概念と同じく)、どちらも「システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」ことである。そのミッションを達成するための手段が、上記のとおりDevは“システムに新しい機能を追加する”であり、Opsは“システムの安定稼働”なのである。つまり、同じ「ミッション」を掲げている

    DevOpsとは何か? そのツールと組織文化、アジャイルとの違い
  • 今の会社

    今の会社に転職して、3年が経過しました。 新卒でメーカー系SIerに入社し 途中、コンサル(とっても中身はパッケージ導入)で働いていましたが 他社製品の導入とそのスケジュール管理に飽きてしまい、再度、自ら開発できる環境を求め現在のSIer転職しました。 が、転職先は見になるような「SIer」でした。 以下、自分と合わない点です。 技術に興味がない 開発しない 品質をステップ数で管理する 会議・レビューが多い 見積りが人月 技術に興味が無い 最新技術についていけないというのではなく、技術自体に興味がありません。 自称技術力の高い上級マネージャが、JavaScript がサーバーサイドとクライアントサイドのどちらで動作しているのか理解していない状態です。 もちろん、Node.jsなど知りません。 開発においても、イントラで利用するシステム&要員確保の点から2016年の開発にStrutsを採

  • モダンな開発がしたい学生が大手IT企業に行く際に知っておくべきこと

    http://anond.hatelabo.jp/20160413023627 を見て触発されたので書く。 タイトルのようなことについて、実態というか現実というか、そういうのを当たり障りない範囲で書こうと思う。全ての企業や学生に当てはまるはずはない(むしろかなり偏見や単純化を混ぜてる)けど、参考になれば幸い。 ちなみにトラバ先は研究を志望したという話だけど、エントリは研究志望というよりは一エンジニア志望向けかも。 前提1: モダンな開発とは?あえて定義はしないけど、Github で公開されてるような OSS を使ってます/いじってますとか、LL 使って Web アプリ作ってますとか、アジャイルやらテストコードやら最近主流の手法使ってますとか、そんな感じで捉えていただければ幸い。あるいはメインフレームで COBOL とか周辺機能を全部車輪の再発明してるC言語製アプリとかそういう古い仕事では

    モダンな開発がしたい学生が大手IT企業に行く際に知っておくべきこと
  • 消えたプログラマの残したものは - megamouthの葬列

    システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい

    消えたプログラマの残したものは - megamouthの葬列
  • プログラムに埋め込まれた業務仕様を自動抽出する技術、富士通研が開発

    富士通研究所は10月11日、業務システムのプログラムを解析し、実装されている業務上の決まりや計算の方法などを理解しやすい条件表として自動抽出する技術を開発したと発表した。大規模化・複雑化したシステムの現状把握の手間を削減でき、システムのクラウド移行などの作業の効率化につながるとしている。 業務システムを移行・再構築する際は、システムの現状把握が必要だが、長年の開発で大規模化・複雑化したシステムは、仕様書が陳腐化したり、開発関係者が散逸するなどしてブラックボックスになっている場合が多く、仕様の把握に多くの時間がかかってしまう問題があった。 富士通研は、大規模なプログラムを分割して業務仕様を掘り起こし、表の形で抽出する技術と、分割された表から全体の表を再構成する技術を開発。実装されている業務仕様を理解しやすい条件表として自動的に抽出でき、現状把握の作業を効率化できるという。 同技術を社内の事例

    プログラムに埋め込まれた業務仕様を自動抽出する技術、富士通研が開発
    n_knuu
    n_knuu 2016/10/12
    こういうのがあったら良いなあと思って作るのと、それを適用できるような実例がある富士通はいい意味でも悪い意味でもすごい会社だなあと
  • 計算量と僕とWeb開発 / computational complexity and I and Web

    TiDBは銀の弾丸になるのか? ~ レバテックの課題と新たな挑戦 ~ TiDB User Day 2024

    計算量と僕とWeb開発 / computational complexity and I and Web
  • 【悲報】みずほ銀行の次期システム、デスマプロジェクトが破綻か。完成のメドなく4000億円がパー : IT速報

    選択出版に掲載された「みずほ「システム更新」が絶望的に。完成のメドなく「四千億円」がパー」という記事が話題。マルチベンダーによる弊害、赤裸々なデスマの現状、その破綻劇がすっぱ抜かれている。 みずほ「システム更新」が絶望的に。完成のメドなく「四千億円」がパー 2016年7月号 デスマーチ― ―。ソフトウエア開発などのプロジェクトにおける過酷な労働状態や、納期などが破綻寸前でメンバーの負荷が膨大になったプロジェクトの状況を指す言葉。文字通り「死の行進」とも呼ばれて・・・ https://www.sentaku.co.jp/articles/view/16013

    【悲報】みずほ銀行の次期システム、デスマプロジェクトが破綻か。完成のメドなく4000億円がパー : IT速報
  • 富士通に入社して10年が経った - blog

    こんばんは tnaotoです。 富士通退職エントリーが何かと話題ですが、いろんなことが混ざっているので一度整理してみようかなと思います 。 昔は、リクルータや採用イベントに出ていたこともあるので、そこらで話をしてたことを思い出しつつ。 突然、この記事が消えたら会社からの圧力があったか、話題になりすぎてビビったかのどちらかです。 anond.hatelabo.jp 自己紹介 僕は約10年前に、新卒入社(情報系院卒)し、 ソフト開発職を5年くらいやった後に、社内公募で研究所に異動し、 以後、事業部と研究所を行ったり来たりしています。 最近では、publickeyあたりに僕のことが乗っていたりします。 www.publickey1.jp また、僕は研究所にはいますが、研究してない研究員という謎の立場です。 富士通の職種 よくSIerがーとか言われる業界ですが、富士通の職種はいろいろあります 。

    富士通に入社して10年が経った - blog
  • つらくないコードレビューの運用 - Speaker Deck

    All slide content and descriptions are owned by their creators.

    つらくないコードレビューの運用 - Speaker Deck
  • 植山 類

    仕事を説明するときに「Google仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」というと、???という反応になることが多いので、こういう仕事をしているんだよということをちょっと説明してみます。...

    植山 類
  • 一緒に働きたいエンジニア像について、リクルートライフスタイルのメンバーが徹底的に議論してみた - はてなニュース

    じゃらんnet、ホットペッパー グルメなど毎日の生活に役立つサイトから、クラウドレジアプリ「Airレジ」などBtoBサービスまで、リクルートライフスタイルは非常に多くの事業領域を手掛けています。ITに対し大きなチャレンジを続けているリクルートライフスタイルの人事とエンジニアが、一緒に働きたいエンジニア像について議論しました。エンジニアの働き方、キャリアパスをどう考えているかも伺います。 座談会出席者(上写真、左より):神山良太さん、小川健太郎さん、副田俊介さん、塚越啓介さん、佐橘一旗さん (※この記事は、株式会社リクルートライフスタイル提供によるPR記事です) ▽ エンジニア採用情報 | リクルートライフスタイル RECRUIT LIFESTYLE ――というわけで、まずは自己紹介をお願いします! 神山 人事部で、IT系の中途採用、サービス開発部隊であるネットビジネス部の人事サポート全般

    一緒に働きたいエンジニア像について、リクルートライフスタイルのメンバーが徹底的に議論してみた - はてなニュース
  • Linux開発環境の基礎知識 - Qiita

    自分が長期間Linuxを使わずに、ある時に急に使うことになったりするのでコピペで使える知識をまとめたものです。自分用のメモですのでエントリとして書くのを少しためらいましたが、同じ境遇の人がコピペで使えれば便利かなと思い記事にしました。 MacOSLinuxではなくBSD系ですが、パッケージコマンドの中に少し紹介してます。 CentOS7などに対応してないのでどなたか編集リクエスト送って頂けると助かります。 個人の設定ファイル ホームディレクトリに設定ファイルがある。 場所 意味

    Linux開発環境の基礎知識 - Qiita
  • Railsパフォーマンス基本のキ

    Railsのパフォーマンスについてよくある問題とそれに対して戦いを挑むために必要なもの。

    Railsパフォーマンス基本のキ
  • 若手開発者の後悔 | POSTD

    (編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間

    若手開発者の後悔 | POSTD
  • CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」

    2. 自己紹介 • 1998年 株式会社ナムコ 入社 • 1999年 蚊取り大作戦 (ナンジャタウン) • 2000年 ディグダグ (パチスロ) • 2003年 ミスタードリラー ドリルランド (GAMECUBE) • 2003年∼2004年 ドンキーコンガシリーズ (GAMECUBE) • 2005年∼2006年 リッジレーサー6, 7 (Xbox360, PlayStation3) • 2006年∼ 社内サウンドライブラリ NUSound アーキテクト 4. リッジレーサー6 Love FOOTBALL リッジレーサー7 鉄拳5 DARK RESURRECTION 鉄拳5 DARK RESURRECTION ONLINE ビューティフル塊魂 エースコンバット6 鉄拳6 ソウルキャリバー レジェンズ スマッシュコート3 ファミリースキー ファ ミリージョッキー もじぴったん プチプチ ソ

    CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」