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