タグ

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

タグの絞り込みを解除

Programmingとprogrammingに関するrydotのブックマーク (1,407)

  • 世界で通用するエンジニアになるための高度な技術記事(英語) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 英語サイトでは、日語のサイトでは絶対に手に入らないレベルの記事がわんさか読めます。今日はCodeProjectよりシステム構築をする上で知っておくべき深い知識を解説した記事を3行要約と共にご紹介します。 C#と.NETの記事 C#や.NETのかなりディープな記事たちです。日語ではあまり見かけない深い部分まで知れます。 ■高パフォーマンスなクラスのデザイン方法 Performance Considerations of Class Design and General Coding in .NET - CodeProject ・クラス

    世界で通用するエンジニアになるための高度な技術記事(英語) - Qiita
  • なぜGo言語 (golang) はよい言語なのか・Goでプログラムを書くべき理由 | yunabe.jp

    結論としてはGo言語には以下のようないくつかの長所があり、現実路線で非常にバランスがとれた言語だと思います。 これらの長所のために失われたメリットも当然いくつもありますが、一定程度以上の規模のプロジェクトで利用する言語の選択肢としては現存するプログラミング言語の中では一番か二番目によいのではないかと思います。 コンパイルが速い (vs. C++) GCとメモリ安全性 (vs. C++) 妥当で現実的なレベルの型安全性 (vs. Python/Ruby) 実行時パフォーマンスが良さ (vs. Python/Ruby) 現実問題、ある程度の規模と期間のプロジェクトになると型検証があるとリファクタリングなどがだいぶ楽になるのでありがたい。 型があるので自然と実行時パフォーマンスも良い 標準ライブラリが整備されている (vs. C++) むしろ標準ライブラリにjsonのparserすら存在しないC

  • Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita

    これは Swift Tweets の発表をまとめたものです(次回開催はこちら)。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました!Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし

    Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい - Qiita
  • 「関数型プログラミングって何?」日本語訳 - Okapies' Archive

    この記事は、技術翻訳 Advent Calendar 2016 の15日目です(枠が空いてたので勝手にお邪魔してます)。前回(6日目)は、id:msyksphinz さんの「個人が趣味技術書を翻訳するという意義について」でした。 今回ご紹介するのは、昨年末に公開された Kris Jenkins さん (@krisajenkins) の "What Is Functional Programming?" です。日語訳の公開については著者から承諾済みです。また、London Functional Programmers meetup での同タイトルの講演動画が公開されています。 関数型プログラミングの考え方は、世間ではどうも小難しい話だと思われている節があります。その理由の一つに、議論の抽象度が(比較的)高いことが挙げられるでしょう。例えば、以前このブログで紹介した「なぜ関数プログラミング

    「関数型プログラミングって何?」日本語訳 - Okapies' Archive
  • 言語処理100本ノック 2015

    言語処理100ノックは,実践的な課題に取り組みながら,プログラミング,データ分析,研究のスキルを楽しく習得することを目指した問題集です 実用的でワクワクするような題材を厳選しました 言語処理に加えて,統計や機械学習などの周辺分野にも親しめます 研究やデータ分析の進め方,作法,スキルを修得できます 問題を解くのに必要なデータ・コーパスを配布しています 言語はPythonを想定していますが,他の言語にも対応しています

  • NLP 100 Drill Exercises - 東北大学 乾研究室 / Inui Lab, Tohoku University

    言語処理100ノックについて † 言語処理100ノックは,言語処理を志す人を対象とした,プログラミングのトレーニング問題集です. 乾・岡崎研の新人研修勉強会の一つであるLearning Programmingで使われています. このトレーニングは,以下の点に配慮してデザインされています. 自然言語処理の研究を進める上で,一度は書いておいた方がよいプログラム 統計,機械学習,データベースなどの便利な概念・ツールを体験する 実用的で,かつワクワクするようなデータを題材とする 研究を進めるうえで重要なプログラミングのルール・作法を身につける モジュール性や組み合わせを考慮しつつ,短くてシンプルなプログラムを書く プログラムの動作を確認(デバッグ)しながらコーディングする 労力を節約する(既存のツール/プログラム/モジュールが使えるときは流用する) 計算資源(メモリ・実行時間)を無駄にしない方

  • 研究者流 コーディングの極意 言語処理学会第19回年次大会(NLP2013) チュートリアル資料(岡崎担当分)

    言語処理学会第19回年次大会 (NLP2013) チュートリアル資料(岡崎担当分) 岡崎 直観 東北大学大学院情報科学研究科 okazaki at ecei.tohoku.ac.jp http://www.chokkan.org/ @chokkanorg 研究者流 コーディングの極意 1 研究におけるコーディングの極意? • 今回のチュートリアルをきっかけにサーベイ – ソフトウェアエンジニア向けの指南書は存在 – でも,研究者向けの資料は数少ない • 自分が修士課程の頃は完全に我流だった – 複数文書自動要約のプログラムをすべてC++で実装 – *NIXを使うスキルはなく,すべてWindows上で実行 – 今から考えると,無駄だらけの実験作法だった • ほとんどの大学では実験の講義があるが… – 研究のためのコーディング作法は教えてくれない 2 繰り返される残念な光景 • 論文の締切前日

  • 研究のプログラミングにおける悲劇を無くすためのGitとテスト - Kesinの知見置き場

    大学の研究に役に立った物シリーズ第3弾です 今回は研究のためのプログラミングのノウハウについてです。 特に、研究におけるプログラミングでの悲劇を防ぐために自分が実践していた方法を紹介をしたいと思います。大学や研究室によっては、このような研究のプログラミングのノウハウの伝承が行われているところもあると思いますが、何かの参考になれば幸いです。 大学の研究で役に立ったものシリーズの記事 サービス編 勉強編 研究のためのプログラミングとは まずは、研究のためのプログラミングに求められる特徴をざっと説明したいと思います。自分の経験からですが、こんなところではないでしょうか。 実験結果が出ないと何も議論できないので、とりあえず速く実装することが求められる コードのモジュール化、速度の最適化は後回しになりがち 計算量が多いタスクでは、24時間実行しても実験が終わらないことがあり得る バグによって実験の結

    研究のプログラミングにおける悲劇を無くすためのGitとテスト - Kesinの知見置き場
  • 専門用語を並べてしゃべる専門家は許せない、という人は愚かである、という話 - たごもりすメモ

    ちょっと最近腹に据えかねる記事がネットで散見されるので敢えてアレなタイトルで、よろしくおねがいします。 なおこの記事は、自分はソフトウェアエンジニアリングの専門家であるので、そのような領域を大雑把に想定して書かれております。が、たぶん他の専門領域においても似たような状況なのではないかと推察しております。 専門用語ばかり使って会話するような人は当のプロではない という言説を最近ちょくちょく見ますね。曰く、普通の人に説明できないようではダメだ。曰く、普通の人でも重要性が理解できないように話せないということは、実際にはお前のやっていることは重要ではないのだ。曰く、専門用語ばかりで会話するようでは実際の能力はわからない、専門用語などわからなくても当に能力がある人にはあるのだ。 んなわけねーだろ。 専門家というのは、非専門家には扱えない問題を扱う専門家だから専門家として働けていて、それなりの待遇

    専門用語を並べてしゃべる専門家は許せない、という人は愚かである、という話 - たごもりすメモ
  • 珍しいSHA1ハッシュを追い求めて - プログラムモグモグ

    「SHA1ハッシュってあるだろう?」 放課後、いつものように情報処理室に行くと、高山先輩が嬉しそうな顔でそう言った。 「ええ、SHA1、ありますね」 「SHA1って何桁か覚えているかい?」 「えっと…」 一年下の後輩、岡村が口を開いた。 「50桁くらいはありましたっけ…?」 先輩はパソコンに向かって何かを打ちはじめた。 現在、情報部の部員は三人しかいない。部長の高山先輩と、二年の自分と、後輩の岡村だ。いや、正確に言うと、先輩の学年にはもう少しいたのだが、もうほとんど部室に来ることはなくなってしまった。無理もない、この季節になると先輩たちは受験勉強で忙しくなる。 「例えば、こういうふうに… 適当なSHA1の長さを…」 echo -n | openssl sha1 | awk '{print length}' 部長だけは今も部活に来てこうやって色々なことを教えてくれている。人曰く、普通に勉強

    珍しいSHA1ハッシュを追い求めて - プログラムモグモグ
  • 高校生にWeb上でプログラミングを教え始めたエンジニアがこの8ヶ月間で得た気づき - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 画像: N高等学校課外授業(N予備校)での生放送授業のブラウザ上での見た目、コメントが書ける 目次 はじめに 教えることになったきっかけ Web企業にエンジニアとして就職できるようになる、というミッション 既存のWeb教材に感じた問題意識 「各自進められるゲームブック形式の教材」と「徹底的にフォローする生放送授業」 コンセプトをもとに構成されたコースと内容 ゼロからプログラミングができるようになった人が生まれた日 永劫、プログラミングは一部の天才たちのためのものか? プログラミング学習のモチベーションの課題と対応 まじめなオタクたちが社

    高校生にWeb上でプログラミングを教え始めたエンジニアがこの8ヶ月間で得た気づき - Qiita
  • テスト計画の立て方 - Qiita

    テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ

    テスト計画の立て方 - Qiita
  • ChalkTalk CLR – COMのすべて

    日は「ChalkTalk CLR – COMのすべて」と題して、COM(Component Object Model)についてのディスカッションを行ってきました。 参加された方はCOM方面に強い方が半数近くいて(MVP4人、元MVP2人、中には現役で開発やってるという人も)、とにかくこれ以上ないぐらい強力なメンバーで、濃い議論が交わされました。多分、もうこういう企画は無いかな感全開 (;´Д`) 遠方からの参加もありがとうございます。 ChalkTalkバンジャーイ この記事では、内容を「要約」して記載します。図については内容を考えて起こしなおしました。 前回と同じく、Maker Lab NAGOYAさんのスペースをお借りしました。ありがとうございました。 事前の洗い出し まず、各参加者のCOMに対してのスキルセットを「バリバリ解説OK」~「COMって何」のレベルで、かつ自分がCOM

    ChalkTalk CLR – COMのすべて
  • Kotlin Programming Language

    Kotlin for BackendSpring support, Java interop, coroutines.

    Kotlin Programming Language
  • null安全を誤解している人達へのメッセージ - Qiita

    null安全を誤解している人達へのメッセージ 先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃ

    null安全を誤解している人達へのメッセージ - Qiita
  • null安全でない言語は、もはやレガシー言語だ - Qiita

    これらは、表中の「リプレース対象言語」に挙げたように、多くのメジャー言語に対する代替手段でもあります。 Java の代わりには Kotlin や Ceylon が、 JavaScript には TypeScript や Flow が、 Objective-C には Swift が、そして PHP には Hack があります。 Python は自身に null 安全 を取り込みました。 Crystal は直接 Ruby と連携して使えるわけではありませんが、 Ruby 風の null 安全 な言語です。 RustC++ の代替を目指して開発され、 Firefox の一部で C++ のコードを置き換えるのに使われています 2 。 null が引き起こしてきた数々の問題を考えると、僕は、 null 安全 は GC (やその他の安全なメモリ管理手法)に匹敵するプログラミング言語の進化だと考え

    null安全でない言語は、もはやレガシー言語だ - Qiita
  • GPGPUでオイル時計のシミュレーションを作ってみた – EL-EMENT blog

    最近の投稿 サイトを新しくしました Unityでスクリプトを使わずに流体を計算する PHPでオンライン対戦できるリバーシを作ってみた ハル研究所プログラミングコンテスト2018に参加しました ワイヤーアクションゲームを作りました 最近のコメントリバーシAIを作ってみた に yukariさんの よりPHPでオンライン対戦できるリバーシを作ってみた に 白丸 よりリバーシAIを作ってみた に taguchi よりPHPでオンライン対戦できるリバーシを作ってみた に ああ亜 よりリバーシAIを作ってみた に Yoka よりアーカイブ 2021年6月 2018年12月 2018年11月 2018年10月 2018年9月 2018年6月 2018年5月 2018年2月 2018年1月 2017年12月 2017年11月 2017年8月 2017年3月 2017年2月 2016年12月 2016年8月

    GPGPUでオイル時計のシミュレーションを作ってみた – EL-EMENT blog
  • 「なぜ関数プログラミングは重要か」を要約してみた(その1) - Okapies' Archive

    関数型プログラミング (functional programming) の利点を説く際によく持ち出されるのが、QuickCheck の開発者の一人である John Hughes が 1984 年に著した論文 "Why Functional Programming Matters" だ。「なぜ関数プログラミングは重要か」という題名で日語訳もされているので、読んだことがある人も多いと思う。 要旨としては、冒頭の1章および2章で述べられている「関数型プログラミングが優れているのは、高階関数と遅延評価という、モジュール同士を貼り合わせる強力な『糊』を持っているからだ」という話がほぼ全てで、以降はそれを具体例に基づいて説明する構成になっている。ただ、その具体例として「数値計算アルゴリズム」やら「ゲーム人工知能アルゴリズム」やらの話が延々と続くし、しかもコード例が Haskell の先祖にあたる

    「なぜ関数プログラミングは重要か」を要約してみた(その1) - Okapies' Archive
  • DHHはどのようにRailsのコントローラを書くのか | POSTD

    私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

    DHHはどのようにRailsのコントローラを書くのか | POSTD
  • DRYと不当な抽象化によるコストについて | POSTD

    記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、

    DRYと不当な抽象化によるコストについて | POSTD