調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
先月、35歳になった。 35歳定年説は「全員に一致する法則ではない」というのは一般的な認識になっている。 前職の同僚で同世代である id:motemen に聞いたところ「そんな事を意識したことなかった」という回答をもらったこともある。 しかし、実際に自分が35歳になると「自分は他人事ではない」という感覚だけがある。 そこで今日はそのことについて考えていきたい。 コードを書くということ コードを書くという行為は年齢関係なく続けていける。 しかし「仕事でコードを書き続ける」となると事情が変わる。 まず費用対効果として自分がコードを書くことが正しいのか？という問題とぶつかる。我々のプログラマーとしての仕事を奪うのはAIではない。いつの時代も 優秀な若者 だ。 そんな若者と比較した時、我々がコードを書くことが若者がコードを書くことよりも費用対効果がある場合はどんな場合だろうか？やはり経験が活かせる
顛末 昨日、こういう感じのツイートを見かけかました。 ポケモンほどの大規模なゲームでHaxe採用されるの初めてなのではhttps://t.co/i8lCJx0NWh— neguse (@neguse) November 14, 2019 結果、このような形となりました。 これは、Haxeという高度な型システム及びマクロシステムを持つ静的型付き言語であり、マルチプラットフォームでC++, JavaScript, C#, Java, Python, PHP, Luaなどのターゲットに出力可能なプログラミング言語の現実世界での利用状況を調査するために購入されたものです pic.twitter.com/UnaZsMrH9I— てろるー (@terurou) November 16, 2019 調査結果 確かにポケモン ソード/シールドの知的財産の表記には、Haxeの記載がありました。 確かにポケモ
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
scalar型を新しく定義するためにはscalarキーワードを使います。例えば、Date型を新しく定義するには次のようにします。 scalar Date スキーマではこれだけですが、実際に使う際はGraphQL処理系に対してさらにシリアライズとデシリアライズを定義することになります。 GraphQL組み込みのscalar型は先にあげたものだけなので、例えばバイナリ、日付と時刻、HTML/XML、BigIntなどを必要に応じて追加することになるでしょう。ただしその場合、サーバーサイドとクライアントサイドでシリアライズ・デシリアライズの実装を一致させる必要があります。 Enum enum（イナム）はscalar型の一種で、特定の値のみを持つ型です。例えば、組み込みscalar型であるBooleanをenumで宣言すると次のようになるでしょう。 enum Boolean { true false
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらの記事内容は3年以上前のものなので、記事内にあるアプリケーションなどの動作やUIは実際と異なる可能性があるのでご注意ください。 (2023/01/04追記) iPadでプログラミングwwwアホちゃうかwww ワイ「え？お前全部iPadでプログラミングしてんの？そんなん効率悪いに決まっとるやんw」 ワイ「せいぜいでっかい画面でGithubのコード眺めるくらいしかできないやろwてかハイライトすらないんじゃn」 ?!(Monokaiで表示されとるやんけ...) ワイ「おっ、おう。シンタックスハイライトくらいはできるんやな。」 ワイ「まあ
Ubiregi Advent Calendar 2018 の 18 日目です。 ユビレジではたくさんのお客様の大量の POS データをお預かりしており、様々なバッチ処理も実行されています。今回は特定のケースでバッチ処理の一部が 30 分以上かかっていた処理を 14 秒で終わるようにした話について書きたいと思います。前回の Ruby 2.5 の SEGV と闘った話 - @watson1978 の日記 に引き続き DTrace を使った話になります。 はじめに ユビレジでは CSV ファイルでお客様が特定のデータをダウンロードしたりアップロードできる機能があります。CSV ファイルにエクスポートしたり、CSV ファイルから DB に取り込む処理を Worker を起動してバッチ処理しています。 大量のデータを保有しているアカウントと同量のデータを用意して手元の環境で試したところ時間がかかるこ
はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上
あるいは、画像コメントのすすめ。 TL;DR 画像コメントのほうが意図が伝わりやすい 画像URLからツールチップで画像表示してくれるVSCode拡張機能があるよ その場で画像を作るSVGエディタもあったよ 問題提起 みなさんは、少し複雑なアルゴリズムを書くことになったときどうしていますか。 たいていの場合、いきなりコーティングに取り掛かるのでなく、 雰囲気をつかむためメモやホワイトボードに落書きすると思います。 特に幾何計算では簡単なものでも図を描いた方がいいです。こんな感じ。 図を書いたら後はコードに落とすだけです。 ね、簡単でしょう？ // 指定した直線を対称軸としたときの指定した点の鏡映位置を返す function flipVectorByLine(p: Vector, line: Line): Vector { // TODO: よくわかるコメントを書く const ln = ne
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに C++を完全理解したので完全理解ガイドを書く。 最初に言っておくがタイトルは詐欺で、実際はポエムである。 僕は仕事でC++を書いたことはないのでなんか変なことを言っているかも知れない。 ところで無職になったので、普通にC++で職がほしい。 2018年6月から受託で仕事をもらい、毎日C++17を書いています。 2018年9月から雇用され、毎日C++17を書いています。 かなり雑に書いているはずなので、コメント等でどんどんマサカリを投げてほしい。 僕は何者か 工学部を卒業して4年ほど高校の理科教師をやっていたが、現在無職になった人
ISSUEに移動しました 関連情報も発信していますのでご購読お願いします。 https://i-ssue.com/topics/ba5df508-fe22-477c-86a6-54471634a375 個人のコードレビューを売り買いできるサービス: https://www.pullimage.com/ pushrequestはpullrequest単位でコードレビューを受けるためのマッチングサービスです PushRequest PushRequestはプログラミング独学者や個人開発者がpullrequestにレビューをもらうことができます。 背景・課題 私は、独学でプログラミングを1年間学びフリーランスになりました。 最初は、Progateを3周・railsチュートリアルを2周し、そこから自分で作りたいものを開発しました。 途中の半年は知り合いの経営者から案件をいただき、主にスクレイピング
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに サーバーサイドプログラミングを勉強していると、自分でWebサービスを作りたいという気持ちがわいてくるものです（私はそうでした）。しかし、ここで大きな問題が立ちはだかります。どんなにすごい機能をつけても、いい感じのデザインのWebサービスでないとそもそも使ってもらえないのです。 試しに、QiitaのトップページのCSSを無効にしてみました。使える機能は変わらないはずなのに、全く使う気が起きなくなりますね。 しかしそうは言っても、フロントエンドの経験がほとんどないとどうすれば見た目をいい感じにできるかがわかりません。今回は、ちょっ
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
会員事業部エンジニアの新井( @SpicyCoffee66 )です。 Splatoon2 で各ルール S+1 以上になるため日々奮闘中のところに MHW が発売されました。 加えて最近ぷよぷよを始めたので、どう考えてもいろいろ計算が合わなくなってきました。 本日おこなわれた Cookpad TechConf 2018 では「クックパッドの "体系的" サービス開発」と題し、社内でどのような点に気をつけて開発サイクルが回されているかをお話しさせていただきました。 動画・発表資料は後日アップロードされる予定ですので、よろしければ合わせてご覧ください*1。 今回は、TechConf 2018 での発表内容から、BML ループの運用について、多少の補足や要約を交えながら書きたいと思います。 サービス開発は難しい まず前提として、サービス開発は難しいです。 その難しさの大部分は、以下の２つの要因から
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
