「オブジェクト指向入門 第6章 抽象データ型」を読んだ - $shibayu36->blog;
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 「オブジェクト指向入門 第3章モジュール性」メモ - $shibayu36->blog; の続きで、「第6章 抽象データ型」を読んだ。 この章では、オブジェクトを適切に表現する記述として、抽象データ型というものを紹介している。これが非常に参考になったので軽く読書メモをとっておく。 抽象データ型とは 抽象データ型の仕様の記述とは以下の4つを記述することであるようだ。 TYPES(型) FUNCTIONS(関数) -> その抽象データ型に適用可能な操作の集合 AXIOMS(公理) -> その抽象データ型が必ず満たす条件 PRECONDITIONS(事前条件) -> 部分的な関数のソース集合の定義域 STACKの例を見
こんなコーディングは退屈だ！ | Yakst
Enkiのco-founderで最高技術責任者（CTO）であるBruno Marnetteが、エンジニアが仕事に飽きて転職してしまわないよう、社内文化をどのように構築しているのかを紹介します。 開発者として、私は2年以上同じ仕事を続けた事がありません。 転職することは私にとって良いキャリアとなりました。私達の業界では転職を繰り返す事はごく一般的なことです。ところが、以前私が働いていた会社は、私の離職に難色をしめしました。中には、私を必死で引きとめようとする人もいました。しかし、私は仕事に飽きてしまっていたため、残ることはできませんでした。 （免責事項：私は多くのプログラマーよりも楽しいプログラミングの仕事をしていたと思います。仕事を変えることが常に最善の選択とは限りません。） 現在私はEnkiのco-founderで最高技術責任者（CTO）です。会社ではエンジニア文化の構築も行っています。
ダレずに開発を走り切る為の習慣
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう！『だるさ』見積り！本当に大事だよ！ [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
WEB+DB PRESS Vol.90にコラムを書いた - たごもりすメモ
明後日ですね、12月23日発売の WEB+DB PRESS Vol.90 の15周年記念エッセイ「私を変えたソフトウェア」にて2ページ、記事を書きました。 たまに(?)このblogでもエモいアレを書いたりしますが、なんかそういうやつです。原稿料をもらってこういうのを書いたのは初めてです。たぶん。 gihyo.jp 内容は本誌を読んでいただきたいんですが*1、要するに今現在に毎日ミドルウェアを読み書きして生活するようになったきっかけは何だったか、という話です。きっかけひとつというわけでもなく幾つか段階があるなあと思ったので、それについてつらつら思い出話のようなものを書いてます。 改めて読んでみると最後の1ステップ(現職への転職)が抜けているのでそこに何の迷いもなかったようになってますが、もちろん実際はそんなことはありません。が、まあそれはソフトウェア開発者としての転機というよりは人生どう生き
業務を通した技術習得の落とし穴
業務を通した学習の落とし穴 新たな技術を習得するのに最も効率的な方法は、業務で使用している技術について学習することです。業務で使用していますので、すぐに業務に役立ちますし、多くの時間その技術に接しているため、効果的に学習することができます。 業務を通じての知識の蓄積は効果的なのですが、落とし穴もあります。それは、業務をこなすのに最低限必要な事柄だけしか学ばないで終わってしまうことです。 たとえば、何年もＣ言語を使用して組込みシステムを作ってきたエンジニアで、ポインタの使用方法を知らない人がいるとは想像できないかもしれませんが、実際には知らない人がいます。なぜ知らないかというと、グローバル変数を多用した設計しかしたことがなく、構造体であっても、決してパラメータとしてそのポインタを渡す設計をしたことがないからです。 長年同じ種類の開発を行っていて、自分は何でもできると思っても、それは、「井の中
Yahoo!ニュースでの複数プロジェクト間の技術分野の取りまとめ方
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ニュース事業本部 開発部の沼田です。 アドベントカレンダーの前日の記事は、Yahoo!ニュースのサービス面についての説明でした。今回は、そのYahoo!ニュースのサービスを作り上げるために、エンジニアがどのような体制で業務を行っているのかという視点で、簡単にYahoo!ニュースの中の人たちの体制を紹介させていただきます。 チーム開発を行っている方々にとってヒントとなることが、この記事の中に少しでもあればいいなと思います。ぜひとも参考にしていただけたらありがたいです。 Yahoo!ニュースエンジニアのおしごと Yahoo!ニュースにて「開発」と名のつくチームに所属しているエンジニアは58名。プロブラミングやシステム運用を行う人がほと
デスマーチ - Wikipedia
この記事のほとんどまたは全てが唯一の出典にのみ基づいています。他の出典の追加も行い、記事の正確性・中立性・信頼性の向上にご協力ください。 出典検索?: "デスマーチ" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2019年7月） デスマーチ (death march) とは、プロジェクトにおいて過酷な労働状況をいう。本来は、コンピュータプログラマのアンドリュー・ケーニッヒ（英語版）によって1995年に示された、コンピュータシステムのアンチパターンのうち、プロジェクトマネジメント上の問題点の1つとして示した言葉である。日本語では、しばしば「デスマ」と略される。 ソフトウェア産業に限らず、コンピュータが関係する一般的なプロジェクト全般で使われるようになってきており、特に納期などが破綻寸前で、関係者の負
もし海外転職を目指している人が目の前に居たらオススメするたったひとつの単純なこと - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
もし目の前に「海外転職を狙ってまして」と言う人が居たとしたら、即座にオススメすることがある。それは 「今週末にその狙っている国の会社で人材募集しているとこ探して履歴書を送ってスカイプ面談をまずはやってみてはいかがですか？」だ。 「いやいやワタシは今スグ海外に移住したり、転職する予定はないんですよ。２，３年後には。。。」というような人であっても今週末にまずは履歴書送って、そこに熱いメッセージも添えて「ぜひ御社の一員となってばりばり働いて、俺様のすげースキルを提供したい。しいてはスカイプ面談を願う。来月ぐらいにはそっちの国に行くから！」と書け、と。別に本当に行かなくてもOk。ここで言う「履歴書出してしまえ」の発想はなにも本気でオファーもらうことが目的ではないからだ。 実はこれは私自身が数年前に日本に居た時にやったことだからオススメしている。私は日本では超ドメスティックな日本企業で海外とはなんの
Developer Training | Test Coding Skills Online - Codility
Your browser (Unknown 0) is no longer supported. Some parts of the website may not work correctly. Please update your browser.
英語しか使わない職場に英語がほとんどできないエンジニアが入ってきた話 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今の会社はシンガポールのスタートアップで小さい会社ながら世界各国から人が集まり、会議、メール、ランチ中の小話まで全て英語で行われている。で、そんな会社になぜかほとんど英語ができないながら、入社してきた人がいる。 彼はアフリカ出身のTで母国語はフランス語だ。いったいどういう経緯ではるばるアフリカからアジアのシンガポールまで来たのかは正直私もまだよく分かっていない。出会ってから半年ほどになるが、なにより英語があまりできないから、そのような基本的なコミュニケーションがまだ取れていないのだ。でもこの「できなければ即クビ」が多いシンガポールのスタートアップにおいて、Tはクビになどならずに非常に重要な仕事を着々とこなしている。 Tが入社する前、会社に必要な技術があってその求人応募の広告を出した。すごくカンタンに言うとAとBとCの技術ができる人を求む。という感じだ。 で、来た候補者はざっと以下の感じだっ
部署の課題を継続的に改善する取り組み - クックパッド開発者ブログ
はじめに こんにちは、投稿推進部の勝間です。 約1年前、「サービス開発エンジニアからマネージャになった話」というエントリを投稿しましたが、現在も試行錯誤しながらマネジメントに取り組みつづけています。 「組織は生きもの」とも言いますが、私の部署もまた生きもののように、日々いろいろな課題が生まれ、それに取り組んでいます。今回は、そのような部署で私が感じた課題と、それに対する具体的な取り組みについて、いくつか事例とあわせてご紹介します。 1. 業務外の問題に目を向ける 私の部署では、毎日約5分間の朝会を開いています。 1人30秒くらいで、「今日取り掛かること」「参加するミーティング」「その他勤怠など含めて共有すべきこと」を共有します。 朝会を行うことでそれぞれの業務的な進捗を確認でき、また、内容について疑問に思ったこともすぐに確認、理解できる状態を作ることができていました。 一方で、業務と直接関
プログラマの心の健康
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
Noといえることの大事さ | プログラマが知るべき97のこと
Noといえることの大事さ著者: 宮川 達彦 自分でつくったソフトウェアを公開し、利用してもらうことはとてもうれしいものです。利用しているユーザからのフィードバックに耳を傾けることはソフトウェアをよりよいものにしていくためにもとても重要なことです。 一方、ソフトウェアのデザインにおける究極の美しさはシンプルさにあると言われます。有名なUNIX哲学では”Write program that do one thing and do it well”(1つのことをうまくやるプログラムを書け)といわれるように、複数の機能をつめ込まず、単一の機能をもったプログラムを組み合わせて使うことが美とされます。 ここにギャップが生じます。ソフトウェアが人気になり、ユーザが増えるにつれ、「あの機能を追加してくれ」「ここの動作をオプションでOn/Offできるようにしてくれ」という要望が出てきます。実際にそうした機能
育ちのよいコード | プログラマが知るべき97のこと
育ちのよいコード著者: 森田 創 高凝集と疎結合が優れた設計の指標だと教わったとき、戸惑ったのを覚えています。あるコードがどのくらい指標を満たしているのか、私達は判断できるのでしょうか。 巨大な関数や相互依存など、凝集や結合のまずさを示す「匂い」があるのはたしかです。鼻をつまみたくなるソフトウェアは誰にも覚えがあるでしょう。けれど一見清潔なコードをみたときも、それが本当にうまい抽象なのか不安に思うことはありませんか。 そんな時は少し視点を変え、コードの生い立ちに目を向けましょう。コードのレポジトリをチェックアウトし、それまでにチェックインされた変更、パッチをよく調べるのです。そのパッチはひとかたまりの「+」行からできていましたか?つまりパッチ単位の変更がファイルをまたがず、1つのファイルの同じ場所にまとまっていましたか? 条件にあうパッチが多いなら、凝縮や結合の指標には期待が持てそうです。
pelletkachels | blog over bedrijven en feitjes en de pelletkachel
Welkom bij Pelletkachels.nl, jouw ultieme bron voor alles wat met pelletkachels te maken heeft! Maar we zijn meer dan alleen een platform voor het bespreken van warmtebronnen. Bij Pelletkachels.nl geloven we dat het delen van kennis en ervaringen over bedrijven en gebeurtenissen ook essentieel is voor het creëren van een betrokken en geïnformeerde gemeenschap. In dit blog duiken we dieper in de we
不具合にテストを書いて立ち向かう | プログラマが知るべき97のこと
不具合にテストを書いて立ち向かう著者: 和田 卓人 テストを行っている品質保証チームや、実際にシステムを使つでいる不具合が報告されたとき、あなたはどう思いますか?悲しんだりよ恥ずかしいと思い、不具合修正にすぐに着手したいと気がはやるというのが人情というものです。しかし、焦っているときに行う作業はしばしば視野が狭く、1つの不具合修正が3つの新たな不具合を生んでしまうということになりがちです。 テスト駆動開発(TDD :Test Driven Development)とは、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。しかし不具合の発生とは、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか? やはりテストを書いて立ち向かつてゆくのです。私はテスト駆動開発を数年間実践してくる中で、心がけ
快適な環境を追求する | プログラマが知るべき97のこと
快適な環境を追求する著者: 舘野 祐一 あなたは1日のうち、一体どれぐらいの時間をコーディングに費やしますか?1時間の人もいるでしょうし、10時間の人もいるでしょう。ほほ毎日続けるとしたら、一生でどれぐらいの時間をコーディングすることでしょうか。 私たちはコーディングをしている時、コードを書く以外にも様々なことを行っています。エディタを操作する・ビルドする・テストを走らせる・ドキュメントを閲覧する・必要なライブラリをインストールする・キーボードを叩く・画面を見る・椅子に座る、などなど細かく挙げるときりがありません。 たとえばエディタを操作することを考えてみましょう。エディタ上であるメソッドが定義されているソースを開きたいため毎回毎回いちいちgrepを駆使して該当ファイルを見つけて開く、なんて経験ありませんか?エディタ自体に簡単に目的のソースを開ける機能があるかもしれませんし、探せば誰かが有
ルーチンワークをフローのきっかけに | プログラマが知るべき97のこと
ルーチンワークをフローのきっかけに著者: 宮川 達彦 ソフトウェア・エンジニアやプログラマはよくアーティストに例えられます。ある人は2時間だけのコーディングで、他の人の8時間分の成果をあげることができます。また、コードの長さは必ずしもその品質やデザインの美しさ、メンテナンス性の高きには比例しません。あるプログラマが朝9時に出社し、夕方6時に退社するとしても、その問ランチをのぞいた8時間、つねにターミナルやエディタを開いてコーディングしつづける、というのはむしろ稀な部類でしょう。 周りの妨げがなくコーディングに没頭している状態を「フロー状態」と呼びますが、このフロー状態に何の苦労もなく突入できるエンジニアを本当の達人プログラマと呼ぶのかもしれません。何しろ、フローに入るための邪魔や誘惑が多すぎます。受信箱にたまった未読メール、RSSフィードリーダーにたまったニュース、頻繁にポップアップするメ
ロールプレイングゲーム | プログラマが知るべき97のこと
ロールプレイングゲーム著者: 関 将俊 ここでは私が実践している、ちょっと良いプログラマになるためのコツを紹介します。まるで「理想のプログラマ」のように仕事をするための簡単なアイデアです。チームでプログラミングするお仕事に就かれているみなさんが、このアイデアで昨日よりも気分よく過ごせるようになれば幸いです。 多くの達人が「理想のプログラマ」とはどういうものか、よいプログラマのあるべき姿、立ち振る舞いを説いてきました。おそらく、みなさんも達人たちが理想のプログラマについて書いた文章を読まれたのではないでしょうか。そして達人たちの示す理想のプログラマ像を想像してそんな人物になろうとしましたよね。みなさんは実際にそうなれたでしょうか。その振る舞いを実践するのはちょっと難しかったりしませんでしたか。 「理想のプログラマ」といった「理想の何か」になるために、本来の自分を変えて別な自分になる必要があり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
変化は来る、生き残っていくために - ゲームクリエイターが知るべき97のこと