タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

Programmingとdevelopmentとprogrammingに関するch1248のブックマーク (102)

  • エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳

    先日、僕が大好きでリスペクトしてるソフトウェアエンジニアさんたちと意見交換会(呑み会)中にソフトウェアエンジニアの信用と信頼について話題になったのでメモ。 僕が「このソフトウェアエンジニアは信用できる」っていうのはどういう指標がありますか?って質問した時に出た意見としては コードに対して何らかの貢献をしている 新規プロダクトの開発など OSSのメンテナンスなど(パッチを送るなど) 自分の持つプロダクトに対する反応など が出てきた。 これらのような「良質なアウトプット」を定期的に行う頻度も大事だよねという感じ。 なるほど、確かにって思ったのだけど更にその中で良質なアウトプットとは何かという話題になった。 ソフトウェアエンジニアの属性 ソフトウェアエンジニアには得手不得手がある。 言語だったりレイヤーだったりで好き嫌いも含めて得手不得手がある。 更にもっと言えば「プロダクトの成長段階」でも得手

    エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳
  • @nekopippi · 猫だけど何か

  • 『テスト駆動開発』を読んで - まめめも

    テスト駆動開発posted with amazlet at 17.10.12Kent Beck オーム社 売り上げランキング: 563 Amazon.co.jpで詳細を見る オーム社さまから電子書籍を贈いただきました。ありがとうございます。 書はテスト駆動開発(TDD)の原典で、たいへん有名なです。が、自分はわず嫌いで読んだことがありませんでした。 というか、TDD 自体もちゃんと理解したことがありませんでした。なんだろう、なんか怖かった。 そんな自分が今回このをいまさら読んでみたら、なるほどこれは確かにいいでした。なんというか、語りたくなる感じ。ということでご紹介。 紹介 テストとプログラムを交互に書いていく開発方法 TDD を、例題を用いて実演していくです。 TDD というと「プログラムより先にテストを書く」というところだけ強調されますが、正直それではよくわからないのでし

    『テスト駆動開発』を読んで - まめめも
  • プログラマーのススメ

    人は全員プログラミングを勉強した方が良い。 プログラミングは簡単だし、IT企業なら開業資金も少額で済む。(最初はパソコン、回線、プリンターがあれば十分) 自己資金で数カ月で軌道に載せれるようなネタしかできない。 IT起業の道のりを教えてあげるよ。 下請け:他人が作って欲しいものを作って納品する=資金を増やす自転車操業の段階。 自社開発:自分で作りたいものを作って売る=自転車操業からストックビジネスに移行する。レベニューシェア=下請けと自社開発の中間のビジネスモデル。 増田に投稿できるってことは、パソコンぐらい持ってるんだろ? 屋や図書館に行って、自分に合った分かりやすいプログラミングのを探してみよう。 仕事を取ってくる方法は、ソニックガーデンのやり方を参考にしたら良い。 https://www.sonicgarden.jp/ プログラミング入門最初に1冊だけ推薦するなら「プログラミ

    プログラマーのススメ
    ch1248
    ch1248 2017/10/27
    日経ソフトウェアが誤ってたり曖昧な可能性あるぞ。雑誌やネットの記事は玉石混交。/紹介してる書籍は良質(東大の授業でも使われてる)
  • frasco.io

    frasco.io 2024 著作権. 不許複製 プライバシーポリシー

    frasco.io
  • 伝説のプログラマーが説く「時間通りに絶対終わらせる」仕事の進め方 - リクナビNEXTジャーナル

    長時間労働が大きな社会問題となっている昨今。「ノー残業デー」や「プレミアムフライデー」など、長時間労働を是正するような取り組みが一部の企業で行われています。けれど「そうは言っても、なかなか早く帰れない」「そもそも仕事が終わらない」と悩んでいるビジネスパーソンも多いのではないでしょうか。 Windows95の生みの親のひとりであり、「右クリック」「ドラッグ&ドロップ」を現在のような形に設計したというソフトウェアエンジニアの中島聡さんは、著書『なぜ、あなたの仕事は終わらないのか』(文響社)が10万部を超えるベストセラーとなっています。著書では「ロケットスタート時間術」を公開している中島さんに、「どんな要因があっても絶対に早く仕事を終わらせる」仕事の進め方を伺います。 中島聡さん UIEvolution Founder / neu.Pen CEO 1960年、北海道生まれ。高校在学中からアスキー

    伝説のプログラマーが説く「時間通りに絶対終わらせる」仕事の進め方 - リクナビNEXTジャーナル
  • レガシーコードの触り方 / Working Effectively with Legacy Code

    オープンセミナー2017@岡山

    レガシーコードの触り方 / Working Effectively with Legacy Code
  • hatebu.me

    This domain may be for sale!

    hatebu.me
    ch1248
    ch1248 2017/04/15
    ざっと見る限り、技術書は割とガチに入る本がちらほら。
  • freee Engineers - Qiita Advent Calendar 2016 - Qiita

    About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)

    freee Engineers - Qiita Advent Calendar 2016 - Qiita
  • SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ

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

    SIerの下請け開発者ってレベル低すぎない? - UXエンジニアになりたい人のブログ
  • 技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記

    ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ? 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから? o 信用できないテストデータ も負債 o 現

    技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
  • 量産型プログラマを撲滅したい

    プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発にの手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な

    量産型プログラマを撲滅したい
    ch1248
    ch1248 2017/01/13
    前職で直属の上司がそんな感じで俺は毎日発狂しそうになった。でも、撲滅した後に待ってるのはユートピアでも無かったりする。
  • (Forum) 私はなぜフレームワークが嫌いか - The Joel on Software Translation Project

    BenjiSmith / 青木靖 訳 2005年9月30日 金曜 私は現在JavaによるWebアプリケーションの構築を計画している(そう、様々な理由のためにJavaである必要があるのだが、それについては今は話したくない)。その過程で私は、ポートレットをサポートしたJSR準拠のMVCロールベースCMS WebサービスJ2EEアプリケーションのコンテナフレームワークを数多く評価した。 機能リストやドキュメンテーションに目を通すのに何十時間も費やしたのち、私は自分の目玉をえぐり出したくなった。 たとえば私がスパイスラックを作ることにしたとしてみよう。 私は小さな木工プロジェクトを前にもやったことがあり、何が必要になるだろうかについては十分に理解している。木片と、それに巻き尺や鋸や水平器やハンマーといった基的な道具だ。 ただのスパイスラックでなく、まるまる一軒の家を建てるのだとしても、私は依然と

  • テスト駆動開発について僕は誤解していた - 偏見プログラマの語り!

    ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや?TDD とは何ぞや?ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは?」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック

    テスト駆動開発について僕は誤解していた - 偏見プログラマの語り!
  • 開発のドキュメントをどこに置くか問題 - $shibayu36->blog;

    最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは

    開発のドキュメントをどこに置くか問題 - $shibayu36->blog;
  • 就職して9年が過ぎる - 兼雑記

    転職して7年が過ぎたというのを読んで気づいたんだけど、そろそろ入社後9年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ わりと重要でない Borgチーム (の周辺) いつのまにやらBorgという名前を普通に言って良くなっている。嬉しい。まあ当時もぶっちゃけ、秘密だから出してないっていうよりは、単に誰もアカデミア的なキャリアに興味が無いから出してなかったんだと思う(私見)。 さて、当時Borgというかクラスタマネージメントのあたりでは、コンピュータのリソースて適当にたくさん使ってるけど、これ節約したらすっげー支出減ったりしない?みたいなのがホットで、なんかとりあえず色々な人々が色んなことをやっていた。い

    就職して9年が過ぎる - 兼雑記
    ch1248
    ch1248 2016/03/15
    Googleの人がGoogleの人に言及してる……。
  • 転職して7年が過ぎた

    これを一部でシェアしたのは2014年なので結構前ですが、エンジニアのキャリアパスを考えるにあたって参考になるかと思って公開します。あくまで個人的な体験談で会社の見解などとは関係ないということに注意してください。 -------- 入社日記念の無料マッサージクーポンのメールを受け取って気づいたんだけど、こないだで入社後7年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ そもそも最初は2007年にGoogle Japanのリクルーターからメールをもらったのがきっかけだった。Google Japanの知り合いから紹介で誘いがきて、「お、これは引き抜きってことかな?」と思ってよろこんで話を聞きに行ったのだった

  • ドメイン駆動設計のためのオブジェクト指向入門

    関西DDD.java 勉強会 2016-3-5 (DDD Alliance 勉強会 2016-1-21 @東京の京都再演版)

    ドメイン駆動設計のためのオブジェクト指向入門
  • Web界から組み込みに向けられた刺客「mruby」はこう使われている

    Rubyの良さを組み込みに」を合言葉とする開発言語「mruby」は公開以来、着実な進歩を遂げ、さまざまな場面での利用も進んでいます。ここでは「Web界から組み込みに向けられた刺客」(まつもとゆきひろ氏)たる、mrubyの採用事例を紹介します。 mruby(軽量Ruby)は経済産業省「地域イノベーション創出研究開発事業」として2010年に始まり、2012年4月にオープンソース(MITライセンス)として公開された組み込み向け開発言語です。「Rubyの良さを組み込みに」を合言葉に開発されたmrubyは発表よりはや3年、たくさんの人々の協力でさまざまな形の改良がくわえられ、現在ではライブラリは170を超え、デバッガー対応の安定版「mruby V1.2.0」が発表(2015年11月)されるなど着実に進化しています。 Rubyは開発しやすい、生産性の高い言語としてWeb開発などに広く使われている言語

    Web界から組み込みに向けられた刺客「mruby」はこう使われている
  • How to C (as of 2016)

    How to C in 2016 This is a draft I wrote in early 2015 and never got around to publishing. Here’s the mostly unpolished version because it wasn’t doing anybody any good sitting in my drafts folder. The simplest change was updating year 2015 to 2016 at publication time. (Update: Many people have submitted revisions, notes, and improvements. All contributions have been incorporated throughout the pa