オープンソースプロジェクトとの距離のとりかた
オープンソースプロジェクトに参加したいな、と思った時、まず最初に問題だと感じるのは英語だと思う。構成員が日本人だけで、日本人に向けてのみ出しているそソフトウェアでない限り、プロジェクトの共通語はふつう英語だ。植山さんの記事には英語で物事を進めることの利点が体験談とともに書かれている。他の記事にも、オープンソースプロジェクトで上手いことやっていくためのひとつとして英語の話が出てくる。一方、英語のせいで参加したくても二の足を踏んでしまう、というのもよく聞く話だ。結論から言ってしまうと、やっぱり読み書きだけでも習得しないと話に入っていくのは難しい。ソフトウェア開発者の多くは多様性に対して寛容なので、英語が不得意という理由で拒絶されることはないだろう。ただ、特別な配慮もしてくれない。 しかし英語の前に、プロジェクトとの距離のとりかたを学ぶべきだと思う。いままでわたしが見てきたり、自分自身がやって良
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
Lispのアイデア | POSTD
Lispと聞くと、冷蔵庫のような大きいサイズのコンピュータや、大文字のアルファベット文字列や括弧の並びといったような過去の時代のことが頭に浮かびます。そう、非常に多くの括弧。何故、オブジェクト指向プログラミングの作成者たちは、そんなにもLispの アイデア に魅了されるのでしょうか。そしてまた、アイデアとされるプログラミング言語というものは、どうやったら説明できるでしょうか。こうしたことを教えてくれなかったコンピュータ科学の教育を責めるべきでしょうか。 Lispは、John McCarthyが書いた Recursive Functions of Symbolic Expressions and Their Interpretation by Machines, Part I という論文によって、初めて世界に登場しました。その中で、McCarthyはプログラミングに新しい多くのアイデアを導入
グローバルゲームジャムでクラス設計をやった話2017 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? お知らせ 2017/11/26開催の「プログラマのためのUnity勉強会」において、 Unity開発で使える設計の話＋Zenjectの紹介 というタイトルで講演しました。こちらのスライドを先に見てから本記事を参照されることをおすすめします。 はじめに 去年に引き続き、今年もGGJに参加してきました。今回もそのことを書きたいと思います。 今回の内容は以前に投稿したUnity開発で便利だったアセット・サービス紹介 & Unityでのプログラミングテクニックとつながりがあるので、こちらを先に読んでからのほうがわかりやすいかもしれません。 Gl
なぜGo言語 (golang) はよい言語なのか・Goでプログラムを書くべき理由 | yunabe.jp
結論としてはGo言語には以下のようないくつかの長所があり、現実路線で非常にバランスがとれた言語だと思います。 これらの長所のために失われたメリットも当然いくつもありますが、一定程度以上の規模のプロジェクトで利用する言語の選択肢としては現存するプログラミング言語の中では一番か二番目によいのではないかと思います。 コンパイルが速い (vs. C++) GCとメモリ安全性 (vs. C++) 妥当で現実的なレベルの型安全性 (vs. Python/Ruby) 実行時パフォーマンスが良さ (vs. Python/Ruby) 現実問題、ある程度の規模と期間のプロジェクトになると型検証があるとリファクタリングなどがだいぶ楽になるのでありがたい。 型があるので自然と実行時パフォーマンスも良い 標準ライブラリが整備されている (vs. C++) むしろ標準ライブラリにjsonのparserすら存在しないC
LINQで簡単DSL
これはもともとお仕事記事として書いていたのですが、いろいろ折り合いつかず流れてしまいました。 まだ書きかけですが、完成させる気もいまいち湧かなかったので、このまま公開します。 サンプルプロジェクトは https://github.com/karino2/BParserDSL に置いておきます。 ------ 概要 LINQとはC# 3.0 から導入された、SelectManyのシンタックスシュガーの事だ。 近年ではRxやSpracheなど、SQL以外の分野でのLINQの活用例も増えてきた。 このシンタックスシュガーを用いてDSLを作る方法を解説する。 SelectManyを定義する事で、とても短時間で強力なDSLを構築する事が出来る。 (以下本文） SelectManyは非常に強力で多くの応用がある事が判明してきていて、最近の言語では大抵言語のコアの文法要素として、このシンタックスシュガー
アプリケーションから例外を投げる派、投げない派 - Shin x Blog
例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R
Java 再帰下降構文解析 超入門 - Qiita
構文を解析するプログラムをパーサと呼びます。実装方法にはいくつか種類がありますが、今回は再帰下降という方式を取り上げます。既存の実装を使うのではなく、1から実装しながら説明します。 この記事ではJavaの新しい言語機能は使わずに、なるべく基本的な文法だけで記述します。 この記事には関連記事があります。再帰下降を理解してから、応用編として読むのが良いでしょう。 Java パーサコンビネータ 超入門 2016.05.12 Java パーサコンビネータ 超入門 2 2016.05.14 JSONパーサーを作る 2016.12.26 四則演算器 構文解析の練習として、簡単な四則演算器を作ります。文字列で式を与えると計算して答えを返します。 例: "1+2*3" → 7 まずは次の計算ができることを目指します。 "12+34+56" → 102 数字 パーサの基本的な考え方として、1文字ずつ順番に見
今から新規でiOSアプリを書き始めるなら。2016年冬 - Qiita
こんにちは @yimajo です。この記事は今から新規でAndroidアプリを書き始めるなら。に大きく影響されています。主な内容として次のような事柄を取り扱っています。 今から書くならこんな設計 こんなライブラリがあるが使ってみた感想 ただ、結論として大して深い内容は書けませんでしたので、がっかりせず、みなさん思い思いにやればいいよっていうことに終着しています。アドベントカレンダーのネタにみなさんも書いてみてはどうでしょう。 言語について Objective-C か Swift か まず最初に言っておくとObjective-CやSwift以外にもiOSアプリを始める方法はあります。例えばObjective-C++とかRubyMotionとか。まあそれはそれで良いところもあると思いますが、複数人でiOSアプリ開発を行いそれを保守したり機能追加したりすることを考えるとObjective-CかS
neue cc - Unity + iOSのAOTでの例外の発生パターンと対処法
Unity、はUnity3Dのほうの話ですが、それで開発していてiOS実機にデプロイして確認すると、以下の様なエラーに悩まされると思います！ System.ExecutionEngineException: Attempting to JIT compile method ひぎぃ！怖い！これはiOSはネイティブコードしか許可していないので、MonoのAOT(Ahead-Of-Time)コンパイラ経由でネイティブコード変換されるんですが、それの関係で色々な制限があるからなのですね。さて、制限があるのはshoganaiんですが、引っかかるのは痛いです、めっちゃ痛いです、辛いです。 というわけで、どういうコードを書けば発生するのか、というのを並べてみました。どうすれば発生するのか分かれば、自然に避けられますからね。そのうえで、幾つかのものはちょっとしたハックで防げるので、それも述べます。あとは、
Realm Swiftのまとめ - Qiita
情報元 Realm is a mobile database: a replacement for SQLite & Core Data https://realm.io/jp/ Swift Docs - Realm is a mobile database: a replacement for SQLite & Core Data https://realm.io/jp/docs/swift/latest/ RealmSwift Reference https://realm.io/docs/swift/latest/api/ realm/realm-cocoa: Realm is a mobile database: a replacement for Core Data & SQLite https://github.com/realm/realm-cocoa Realm for S
GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決
, 『エンタープライズアプリケーションアーキテクチャパターン』 - 角谷HTML化計画(2005-04-21)
■1 『エンタープライズアプリケーションアーキテクチャパターン』 献本いただきました。ありがとうございます。カバーに刷られているタイトルが3D(?)になっている。エンボス加工ってやつ？ ちなみにオビはtypoバージョン。一般発売分は、typoが修正されているらしいので、レアものだ(って、バグなわけだが。バグにプレミアはつかないよな)。 さて。本日到着したところで、中身はまだ少ししか読めていないのと、ちょっと時間が足りないので、軽めに。 パターン名は基本的に原著パターン名をそのままカタカナで、区切り文字無しで並べたもの。ユニットオブワーク、マネー、ツーステップビューなどなど。なんか競走馬の名前みたいだが、一貫性があれば、それはそれでひとつの見識だし、原著のパターン名との対応もわかるのだが……残念。一貫性はないし、本文中に原著パターン名との対応もない。顕著なのは、 「軽オフラインロック(Opt
PofEAA到着
cles::blog 平常心是道 blogs: cles::blog NP_cles() « 足し算銀行。 :: ck - terminal emulator » 2005/04/23 PofEAA到着 objectoriented softwareengineering 24 2へぇ 今日は講演を聞くために土曜日にもかかわらず大学に行ってきました。会場で開演を待っていると、講演にやってきたとある先生から「Amazonに本をたのんだよね？」という突然のクレームが。 何かまずいことをやらかしてしまったのかとちょっと焦りましたが、要はその荷物で大学の郵便受けがいっぱいになってしまっていたということでした。注文したのは木曜日の夜だったので、１営業日で届いてしまったということになります。Amazon恐るべし。 † とりあえず訳本と原著を一緒に 「訳本を読むんだったら、原著くらい持っていないとね
わかりやすいドキュメントを書くには 〜 全体像を把握できることが重要 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに エンジニアなら誰でもたくさんのドキュメントを読むことになります。 その中にはわかりにくいドキュメントも少なからずあると思います。 自分はわかりにくいドキュメントは「全体像が掴みにくい」ことが多いと感じています。 そこで、ここではわかりやすいドキュメントを書くための方法を「全体像を把握できるようにする」という視点でまとめてみました。 また、最後に具体例としてQiita APIドキュメントでわかりにくい点の指摘と改善をしてみました。 ここで扱うドキュメントの種類 ここでは仕様書やリファレンスマニュアルといった類のドキュメントを想定
『DIコンテナとドメインモデルの相性の悪さ』
Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[C#・LINQ]九九だけじゃない！アプリ開発にもゲーム開発にも使える、SelectMany! - Qiita![[C#・LINQ]九九だけじゃない！アプリ開発にもゲーム開発にも使える、SelectMany! - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3d9230b3d7372856422e4db6498a32245c55e0c9/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNDEyNSUyRnByb2ZpbGUtaW1hZ2VzJTJGMTY2NDM2ODY1NT9peGxpYj1yYi00LjAuMCZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmZm09cG5nMzImcz1mY2ZlN2ExMjM2M2Q3ZjZkYTY3YWZhYmIzNzVmYjQzMQ%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253De9a367b49eb57e103946d6d94704167a%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCQyUyMyVFMyU4MyVCQkxJTlElNUQlRTQlQjklOUQlRTQlQjklOUQlRTMlODElQTAlRTMlODElOTElRTMlODElOTglRTMlODIlODMlRTMlODElQUElRTMlODElODQlRUYlQkMlODElRTMlODIlQTIlRTMlODMlOTclRTMlODMlQUElRTklOTYlOEIlRTclOTklQkElRTMlODElQUIlRTMlODIlODIlRTMlODIlQjIlRTMlODMlQkMlRTMlODMlQTAlRTklOTYlOEIlRTclOTklQkElRTMlODElQUIlRTMlODIlODIlRTQlQkQlQkYlRTMlODElODglRTMlODIlOEIlRTMlODAlODFTZWxlY3RNYW55JTIxJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9NjA2YWQwNDliYTgxYTdhNmIzNjI4Y2Y2ZDc5ZTJmZDE%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDBSeW90YU11cm9ob3NoaSZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1wYWQ9MCZzPWFiNWU1MDVkNDE5NDI0M2Q4YjNkOTRiYWJiOWI2MGQ3%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D0895bc9f832bb7e350c8227e12f98d61)
SelectMany: Probably The Most Powerful LINQ Operator
Realm for Swift まとめ完全版 - Qiita
