■PHPerKaigi 2019の登壇資料です - https://phperkaigi.jp/2019/ - https://fortee.jp/phperkaigi-2019/proposal/328896eb-c084-41c9-847f-f0512a538811 ■前作 - 失敗から学ぶ、RDBの正規化の話 - https://soudai.hatenablog.com/entry/learn-from-failure-1
Scalaは最初から関数型プログラミングのスタイルで書くことを意識して設計されたという意味で関数型プログラミング言語と言えますが、一方で、「Better Java」な手続き型スタイルで書くことも基本的には否定されるべきではないと思います。たとえば、ビッグデータ関係のソフトウェアとして有名なApache SparkはScalaで書かれていますが、(おそらく)パフォーマンス上の理由のため、手続き型のスタイルで書かれている部分がかなり多いです。 さて、それはいいのですが、そういう「Better Java」なScalaコードによく見られるパターンに、変更可能コレクションを使っているのに、そのコレクションを格納する変数をvarとして宣言しているものが(割と有名なソフトウェアでさえ)あります。ですが、そういうコードは 書いてはいけません(かなり例外的な場合を除いて)。 「書いてはいけません」というのは
ラウンディングエラー(Rounding Errors, 丸め誤差) どういうこと? 【したいコト】 小数点を含むような数値を格納し、数学的な計算を行います。 【やらかしたコト】 データ型に「FLOAT」を使用します。 どうしてヤル? プログラミング言語には、floatという、実数を表すデータ型があります。 データベースにも同じ名前のFLOATデータ型があります。プログラミング言語のfloat型と同じように、IEEE754標準に従って実数を2進数形式でエンコードします。 float型を用いたプログラミングに慣れているプログラマは、小数値のデータが必要な場合には、当然のようにデータベースのFLOATデータ型を選択します。 どうしてダメ? 丸め誤差が発生します。完全に正確な値を取り扱うのは不可能です。 「1/3」のような有理数を小数で表すと、「0.333...」のような循環小数となります。無限精
メタデータトリブル(Metadata Tribbles, メタデータ大増殖) どういうこと? 【したいコト】 スケーラビリティを高めたいと考えています。クエリの実行速度を劣化させずに、データが増加し続けるテーブルに対応できるよう、データベースの構造を設計します。 【やらかしたコト】 行数の多いテーブルを、複数のテーブルに分割します。そして、テーブルの属性の区別しやすいデータ値に基づいて、テーブルを命名します。それには、たとえば「年度」などがよく使用されます。 どうしてヤル? 行数が少ないテーブルへのクエリ実行の方が、行数が多い場合よりも速く処理できます。 どうしてダメ? テーブル(=メタデータオブジェクト)を意識しなければならない データを見て、挿入先のテーブルを選択しなければなりません。 たとえば、年度別のテーブル場合、新年度のデータのために、新しいテーブルが必要になります。 データ整合
書籍「SQLアンチパターン」より、データベースにまつわるアンチパターンをまとめます。 また、データベースの基礎知識に曖昧なところがあったので、アンチパターンの前に復習しておきます。 基礎知識の復習 テーブルの定義 テーブルの関連の分類 テーブルの役割の分類 キーの分類 論理設計 アンチパターン名 英語 日本語 ジェイウォーク Jaywalking 信号無視 ナイーブツリー Naive Trees 素朴な木 IDリクワイアド ID Required とりあえずID キーレスエントリ Keyless Entry 外部キー嫌い エンティティ・アトリビュート・バリュー Entity-Attribute-Value (EAV) 汎用的な属性テーブル ポリモーフィック・アソシエーション Polymorphic Associations ポリモーフィック関連 マルチカラムアトリビュート Multi-Co
アンチパターンの元祖本、書籍「アンチパターン ― ソフトウェア危篤患者の救出」から、プログラミング活動に関わるアンチパターンをまとめます。 全体構成便宜上「プログラミング編」と銘打っていますが、書籍のカバレッジは広く、「コード」「アーキテクチャ」「プロジェクト」の3カテゴリあります。プログラミングそのものからズレているカテゴリもありますが、全アンチパターンもれなくまとめます。 本書籍で紹介されているアンチパターンは、内容は古くなっているものも多いですが *1 、名前がエキセントリックで、アンチパターンの状況をうまく「揶揄」しています。この後に生み出されたアンチパターンの命名傾向に、大きな影響を与えています。 一覧 コード 肥満児 絶え間なき陳腐化 溶岩の流れ 曖昧な視点 機能的分解 お邪魔妖怪 蛇足 打ち出の小槌 梯子外し スパゲティコード 入カクラッジ 地雷原 切り貼りプログラミング 暗
アンチパターンなので、見出しの内容はすべてバッドノウハウです。 前に書いたやつ PHPのモダンな開発環境を紹介する - Qiita PHP - Functoolsを作った - Qiita PHPのlist()はタプル展開のための機能 - Qiita 関係ないけどこれも: シェル、ターミナル、コンソール、コマンドライン 追記: 本文中でとりあげた「怖い話」について、ちゃんと説明しました PHP - namespaceとBOMに何の関係があるのさ - Qiita ファイルの最後に?>を書く PHPコードは<?phpで始まり?>で締める。それがPHPの常識(キリッ ……そんなことはもう綺麗さっぱり忘れよう。PHPはテンプレートエンジンではあるが、Webアプリケーションを書く上では、もはやテンプレートエンジンとしての機能は求められなくなりつつある。 不要な?>を書いてはいけない理由は明確で、<?p
対象加害者被害者マネジャー=>プログラマどういうこと?プログラマの理想は、「フロー状態」になっていることです。フロー状態とは、一つのことに没頭し、瞑想のような状態になることです。この状態に入ると、幸福感で一杯になり、時間に対する感覚がなくなります。「ついちょっと前、仕事にとりかかったと思っていたのに、時計を見るともう3時間もたっている」というような感覚です。こうなると、「真面目にやれ」と叱宅激励する必要など全くありません。プログラミング作業は、自然に、スムースに流れていきます。ただ、フロー状態に入るため、また、それを維持するためには「連続した時間」が必要です。この確保を妨げるのが、オフィスで発生する様々な「割り込み」です。マネジャーに声をかけられたり、会議があったり、周りで議論が始まったり、電話が鳴ったり、メールの通知が表示されたり、と、オフィスには様々な割り込みが発生します。割り込みが生
対象加害者被害者会社=>プログラマどういうこと?開放型オフィスとは、オフィスを間仕切りなしにして、大きな部屋に一様に机を並べるレイアウトのことです。これは、知的な作業をするには最悪の環境です。騒々しく、余計な割り込みが多く、プライバシーのかけらもありません。とても機能的とは言い難く、そんなオフィスでいいプログラムが生まれるわけがありません。どうして?プログラマの生産性について、科学的根拠のある方法で計測しようとしても、極めて曖昧で複雑なものになります。やっていることが違えば、計測方法も異なります。計測の専門的な技術が要求されますし、分析も時間をかけて慎重に行わねばなりません。生産性が重要なのはわかっていても、効果が測りにくく、かつ時間がかかってしまうので、一時的だとしても、わかりやすいオフィスコストの削減を優先してしまうのです。どうすれば?プログラミングには集中できる環境が必要です。オフィ
対象加害者被害者マネジャー=>プログラマどういうこと?歴史学者の間では、「この世には二つの価値観がある」というのが定説になっています。一つは、スペイン流の考え方です。これは、「地球上には一定量の価値しかないので、豊かになる道は、大地や民衆からいかに富を絞り取るか」というものです。もう一つは、イギリス流の考え方です。これは、「価値は発明の才能と技術で創造するもの」というものです。スペイン流とイギリス流、どちらが優れているかは歴史が証明しています。イギリスでは産業革命が起こり、スペインでは新大陸の原住民搾取に明けくれ、大量の金を持ち帰り、ひどいインフレが発生しました。にもかかわらず、スペイン流の価値観は、現代のマネジャーの間に、今も脈々と生き続けています。マネジャーが生産性について言及するのを聞いていると、すぐわかります。生産性とは、本来「1時間当たり、どれだけ多く作れるか」ということですが、
対象加害者被害者マネジャー=>プログラマどういうこと?ソフトウェアの開発作業は、工場における大量生産とは本質的に異なります。しかし、開発作業のマネジャーやそれに携わる人々は、製造作業の管理哲学を、無意識のうちに受け入れています。ファーストフードの店長になったつもりで、その管理哲学を思い浮かべてみると、次のようなやり方は、ある程度理にかなっているようにみえます。エラーを叩き出せ。機械を極力スムーズに動かせ。人間も同じだ。仕事でへマをやった奴は厳罰だ。人はいくらでも補充が効くものとして扱え。決めたやり方を手早くやれ。 どうやってスピードを上げるかとか、何をやめたらよいのか、ということは決して考えるな。作業手順を標準化せよ。万事、マニュアルに従え。新しいことを試みるな。それはお前の仕事ではない。ただ、このやり方はファーストフード(あるいは製造作業)ではうまくいくかもしれませんが、ソフトウェア開発
この記事は Perl Advent Calendar 2014 の 15日目 の記事です。 14日目の記事は karupanerura さんの Carton時代の必須インストールモジュール(Webアプリ編) でした。 目次 はじめに $classと$self mapの使い所 doブロック内でreturn 終わりに 明日は はじめに はじめに言っておきますが、Perlを分かってそうで分かってない人 = 僕 です。 この記事では、Perlの扱いにある程度慣れてきたけれど、実はあんまり理解せず使っています、という方が陥るであろうミスをアンチパターン形式で紹介する。と見せかけて僕の恥ずかしい失敗というか、勘違いを書いていきます。 $classと$self Perlでメソッドを定義するとき、私は全てこういう風に書き始めていました。 sub method { my $class = shift; #
(150522追記)本稿の続編としてAngularJSモダンプラクティスを掲載しました。本稿は2014年9月に執筆し、情報がかなり古くなっています。続編では、AngularJS 1.4やAngular 2に関する情報をまとめ、入門者への新鮮なチュートリアル、熟練者の移行手引として作成しました。どうぞご覧ください。 この記事は記録のため残します。 AngularJS歴1年の筆者による個人的なAngularJSアンチパターン集です。自分のための戒めとメモを兼ねています。個人差があると思いますので、参考程度に。 また、筆者はTypeScriptで書いています。 Components ComponentsのDI数が6以上になる 危険度★★★ angular.module('myApp') .service('FooService', [ '$q', '$resource', '$rootScope
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く