英語の技術文書を早く読むには - Qiita
英語の技術文書を早く読むにはどうしたらいいでしょうか。 注意: この記事の目的は「技術文書について」「早く大意を読み取る」ことを目的としています。 技術文書でないもの，例えば，小説や詩には当てはまりません。 技術文書を読む場合でも，例えば，「論文を批判的に読むとき」や「扱いが悪いと故障する可能性のあるハードウェアのマニュアルを読むとき」には精読すべきですので，この記事は当てはまりません。 頻出英単語を覚える もし「英語の技術文書を早く読みたい！」と悩んでいるとしたら，多くの場合，英語の技術文書を読むのに，英単語をほぼ全て辞書を引いている，という状況だったりするのではないでしょうか？ もしそうでしたら，正攻法となる主な対策は，頻出英単語を覚えるということだと思います。 例えば英語で書かれた論文があったとします。聞いたところによると， 70%は頻出英単語トップ1500(だったと思います。うろ覚
敗北者のTypeScript - Qiita
TypeScriptはJavaScriptに静的型を導入したプログラミング言語で、登場から現在までその人気を増し続けています。 動的型付き言語であるJavaScriptに静的型の安全性（コンパイル時にバグ・間違いを発見することができる能力）を与えることで、TypeScriptはJavaScriptによる開発の効率を上げてくれます。 裏にJavaScriptがあるという特性もあり、TypeScriptは「部分的に静的型チェックをする」というような挙動をサポートしています1。詳しくは後述しますが、これによりJavaScriptからTypeScriptへの移行が可能となっています。TypeScriptは@ts-check（あるいは@ts-ignore）などを通じてこのようなユースケースも手厚くサポートしています。 このことの裏返しとして、TypeScriptを利用するときは注意すべき点があります
DI (依存性注入) って何のためにするのかわからない人向けに頑張って説明してみる - Qiita
追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス
正しさとGo - Qiita
はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGoの本体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上
AVX-512を用いた、たぶん世界最速のBase64エンコード実装について - Qiita
この記事で紹介するのは高スループットなBase64エンコードの実装方法です。 Base64は、Webの世界を始めとして、世界中さまざまな箇所で使われているエンコード方式です。とてもよく使われるので、高速化についてもしばしば研究されてきたようです。 高速化の最新成果として、2019年10月に、Wojciech Muła, Daniel Lemireによる新しい論文がarxivに投稿されました。なかなか強烈なタイトルが付いています。 Base64 encoding and decoding at almost the speed of a memory copy 論文の主張としては、x86 CPUの持つ最新の命令群を駆使することで、非常に高効率なBase64エンコード・デコードが実現できたというものです。このQiita記事では論文の内容の一部を紹介します。 Base64は問題としては単純に見え
プログラミング言語の習得に必要なもの - Qiita
はじめに 先日、エンジニアの能力と今どきの難しさというタイトルの記事（2018年）を読んで、「これはほんとにその通り」と思う一方で、具体例がないためにピンと来ない人や、マウント取りではという意見も多数見られた。というわけで、自分が比較的得意な、プログラミング言語の構文解析といった分野に関して、この記事の言わんとしていることを補足するような記事を書こうと思い至った。 記事中では、エンジニアに必要な知識や経験を、「ベース」「カテゴリ」「実行環境」という形（以下）に分けて論じている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの 低レイヤー ②カテゴリ フロントエンド / バックエンド / クライアントアプリなど ③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど この中で、特に印象的であり、かつ「よくわかる」と思ったのは以下の記述だ。 ③は比較
printfに4285個アスタリスクをつけるとclang++が死ぬ - Qiita
def check(n) s = "*"*n f = open("test.cpp","w") f.puts <<EOS #include <cstdio> int main(){ (#{s}printf)("Hello World\\n"); } EOS f.close() return system("clang++ test.cpp") end check(ARGV[0].to_i) $ ruby check.rb 10000 clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 10.0.1 (clang
ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話 - Qiita
※ 本記事は自分が運営しているブログに転載しています。 株式会社LITALICOでWebエンジニア（Rails）を担当しています、@YudaiTsukamotoです。 この記事は『LITALICO Advent Calendar 2017』14日目の記事です。 今回は、実務でペアプロを導入したことで、ペアプロへの考えが180度変わった話について書こうと思います。 はじめに この話は、弊社のとある新規プロジェクトの立ち上げで実際にペアプロを導入した話です。 プロジェクトでは初期メンバーとして私を含めた4人の開発者がアサインされました。過去のプロジェクトで比較的うまく機能していたアジャイルの導入や、ソフトウェアテスト・静的解析ツール等を徹底してコードの品質を担保するなど、アプリケーション開発する上での準備を入念に行いました。 そんな中、同じプロジェクトにアサインされた同期の@Takuan_Oi
「サイゼリヤで1000円あれば最大何kcal摂れるのか」を量子アニーリング計算(Wildqat)で解いてみた。 - Qiita
「サイゼリヤで1000円あれば最大何kcal摂れるのか」を量子アニーリング計算(Wildqat)で解いてみた。量子コンピュータナップザック問題量子アニーリングqubowildqat こんにちは！初投稿です！ この記事が誰かに何かでためになれば幸いです！ 背景 僕は先日、この記事↓↓を読んでふと思いました。 サイゼリヤ1000円ガチャをつくってみた(Heroku + Flask + LINEbot) 「サイゼリヤで1000円あったら最大で何kcal取ることができるんだろう？」と。 最近、最適化計算を得意とする量子アニーリングの勉強を始めたこともあって、ナップザック問題をそのまま使えば、計算できるんじゃないか？と思い、早速実験してみました。 ナップザック問題とは ナップザック問題とは重量制限のあるリュックに、値段と重さが定義されたアイテムを詰め込むとき、値段を最大化させるアイテムの組み合わせは
「設計なんて不要でしょ」について - Qiita
経緯 以前とある席で偶然シニアエンジニアの方と設計について議論することがありました。 その時に特に耳に残っていたのは以下の様な内容です。 クリーンアーキテクチャってテストしやすくする為のですよね？ 設計はコード書ける人が他のコードを書ける人に威張るための道具なのではないか？ 設計を学習するならブロックチェーンとかを勉強して技術力を高めるべきなのではないか？ リーダブルコードさえ読んでいれば設計は必要ないのではないか？ 設計なんて不要でしょ その方はかなり詳しく設計の歴史をしっていて尤もな事を言っていましたが、平成も終わる頃においてはその限りではないです。 なので平成最後の日にそれら全てに対して最終的に解答できる形で設計の有用性を説明し、気持ちよく令和を迎えます。 注意: 一応ここで説明する内容や要素も一面だけです。 よくある誤解 クリーンアーキテクチャといえばこの有名なリングですよね。 こ
リーダブルコードを読んだので、殴り書き - Qiita
俺の名はケンヤ。難事件をいくつも迷宮入りさせたニート。しかし ある時謎の組織に入社し薬を飲まされ身体が縮んで Braian になっちゃった。 「面白いコードと読みやすいコードは違う」 「コードは理解しやすくなければいけない」 「コードは他人が最短で理解できるコードでなければならない」 「コードは短い方がいいが、"理解するまでにかかる時間"を短くするほうが大切」 名前に情報を詰め込む 明確な単語を選ぶ 例えばGetではなく、状況に応じてFetchやDownloadなどを使う. tmpやretvarなどの汎用的な名前をさける ただし、明確な理由があれば話は別。 具体的な名前を使って、物事を詳細に説明する ServerCanStart()よりもCanListenOnPort()のほうが明確だ。 変数名に大切な情報を追加する ミリ秒を表す変数名には、後ろにmsをつける。これからエスケープが必要な変
役割駆動設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい
全言語で気をつけるべき、ファイル書き込み時のお作法 - Qiita
言いたいこと 重要なファイルを書くときは、予期しないOSシャットダウンなどを考慮した書き方にする必要があるというお話。 お作法を知らないと、中途半端なファイルや空ファイルが生成され、システム起動時や連携システムで致命的なことになる。 例としてC言語/Java/Python/JavaScript(node.js)を挙げるが、ほぼすべての言語で対策する必要あり。 背景 本番運用されているソフトウェアが起動しなくなるという致命的な不具合が発生した。 ログやコンフィグファイルを収集・解析したところ、コンフィグファイルがぶっ壊れていた。 コンフィグファイルは起動時に読まれるが、必要に応じて書き込まれることもある。 コードを追っていくと、書き込み処理中に強制終了したりすると、中途半端に書かれる可能性があることに気づく。 使い終わると電源がぶち切りされる運用をされており、奇跡的にタイミングが重なったのか
ドメイン駆動設計における２つの『不変』 - Qiita
この記事は ドメイン駆動設計 advent calendar 11日目 の記事です。 日本語版だとわかりずらい「不変(不変条件)」 エヴァンスのドメイン本では、頻繁に「不変(不変条件)」という言葉が出てきます。Kindleで検索してみたところ、83件でした。 分類してみると、主に2箇所でよく使われています。 １つは「ValueObject(値オブジェクト)」の項。もう一つは「Aggregate(集約)」の項です。 Factoryでも多く使われていますが、こちらはAggregateの不変条件に関連する内容ですね。 さて、実は「ValueObject」と「Aggregate」で使われている「不変(不変条件)」の意味って全然違う意味なんです。 弊社でドメイン駆動設計の読書会をしているなかで、話題になり目から鱗が出てしまったので紹介しますね。 「ValueObject」と「Aggregate」の項
「赤の他人」の対義語は「白い恋人」 これを自動生成したい物語 - Qiita
背景 「造語対義語」がちょっと面白いと思ったので、Word2Vecを応用して機械に作らせてみよう！という試み。 やりたいことは、以下のようなギャグ対義語を自動生成すること。 「赤の他人」⇔「白い恋人」 「ウサギは寂しいと死ぬ」⇔「ゴリラは孤独を背負い生き抜く」 「生きろそなたは美しい」⇔ 「死ねブス」 「冷やし中華始めました」⇔ 「おでんはもう辞めました」 「コアラのマーチ」 ⇔ 「ゴリラのレクイエム」 「やせ我慢」 ⇔ 「デブ大暴れ」 「生理的に無理」 ⇔ 「理論上は可能」 「ゲスの極み乙女」 ⇔ 「ほんのりピュア親父」 「週刊少年ジャンプ」⇔「月刊老人スクワット」 「お母さんと一緒」 ⇔ 「お父さんは別居」 「そんなんじゃ社会に出てから通用しないぞ」 ⇔ 「それだけの力があれば幼稚園では無敵だろう」 果たしてWord2Vecを活用して、このようなユーモアを生み出せるのか！？ 本投稿の内
TypeScriptの型初級 - Qiita
この記事は「TypeScriptの型入門」の続編です。入門の続編ということなので初級というタイトルにしてみました。TypeScriptの型よくわからんという方は先に入門から読むことをおすすめします。入門レベルのTypeScriptくらい分かるよという方は読まなくても大丈夫です。 TypeScriptの型入門 さて、前回の記事ではTypeScriptの型を一通り紹介しました。この記事ではその続編として、実用上必要になるTypeScriptの型の挙動を理解したり、標準ライブラリに存在する型の使い方を理解することを目標にします。前回に引き続き、あくまでTypeScriptの型に関する話ですから、JavaScriptの言語機能とか、TypeScriptの構文とかの話はしません。悪しからずご了承ください。 最終更新： 2019-03-16 (TypeScript 3.4に対応しました） union型
【React】新機能hooks - Qiita
はじめに 会社で色々な事件に巻き込まれしまってなかなか書けなかった不幸な日々でした。 ちょっと乗り遅れた感あるんですが、自分の勉強と理解がてら新しい機能であるhooksを書いていきます。 hooksはclassを書くことなくstateとか、色々な機能を使うことができる新しい機能です！React v16.7.0-alphaから使えます。 create-react-appでつくると、僕がやってみたときは16.6だったので、ちょっとアップデートしないとできないので注意です。 そして、かつてはSFCと呼ばれる関数定義のコンポーネントたちも、ここではSFCではなくFCになります。 なにせstatelessではないからね・・・！！。 state この機能を使うと、functional componentがstateを扱えるようになります。ちゃんとre-renderされようとも値を保持してくれるみたいで
さいきょうの二重サブミット対策 - Qiita
この記事はシステムエンジニア Advent Calendar 2015 - Qiitaの記事です。 弊社アーキ部で@kawasimaさんに教えてもらったさいきょうの二重サブミット対策について書いていきます！ 二重サブミットが発生するケース 不正な更新リクエストが発生するケースとして、以下のものが考えられます。 サブミットボタンをダブルクリックする 戻るボタンで戻って、再度保存ボタンを押す 完了ページでブラウザリロードする CSRF攻撃による不正な更新リクエスト 1. サブミットボタンをダブルクリックする 確定ボタンをダブルクリックすることによって、ユーザが意図していないリクエストが発生してしまうケース。 2. 戻るボタンで戻って、再度保存ボタンを押す 処理完了画面から戻るボタンで前の画面に遷移し、再び確定ボタンを押すケース。 本来は入力➡︎確認➡︎完了の画面遷移が適切だが、その画面遷移にな
茨城県と栃木県のデータがおかしいときに確かめること - Qiita
都道府県別のデータを扱う機会ってありますよね． 私もとあるサービスの都道府県別データを解析しておりました． $ wc -l location_data/location-*.csv | sort | head 0 location_data/location-8.csv 0 location_data/location-9.csv 12 location_data/location-38.csv 14 location_data/location-36.csv 20 location_data/location-31.csv 26 location_data/location-32.csv 29 location_data/location-16.csv 33 location_data/location-18.csv 48 location_data/location-39.csv 52
キズナアイとねこますの声を入れ替える機械学習をした - Qiita
最近バーチャルユーチュ－バーが人気ですよね。自分もこの流れに乗って何か作りたいと思い、開発をしました。 モーションキャプチャー等を使って見た目を変えるのは かなり普及しているっぽいので、自分は声を変えられるようにしようと開発しました。 やったこと キズナアイさんとねこますさんの、それぞれの声を入れ替えられるようにしました。これによって、ねこますさんのしゃべった内容を、キズナアイさんの声でしゃべらせることができます。(逆も) 機械学習手法の一つであるCycleGANを用いて、変換するためのネットワークを学習しました。 パラレルデータ(話者Aと話者Bが、同時に同じ内容を話した音声)が必要ありません 。YouTubeから拾った音声でも変換ができます。 当然ですが、一度学習すれば、利用時には何度でも繰り返し利用できます。 期待できる効果 見た目だけでなく、声まで美少女になれます。やったね。 他にも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
