ブコメにただ本文の一部を引用してる人って何なの？
すごく腹たつ。 ″″←これで括ってるやつとか。 それに星をつける人の神経も分からん。 自分の言葉や自分の感想がないのか 追記 どうでもいい記事伸びすぎだろビビったわ お前らほんとはてなブックマークとその機能が大好きなんだなぁ 良かった良かった
自社製品で食べていけるようになるまでやったこと
ミドルウェアのパッケージ製品で食べていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、
ソート可能なUUID互換のulidが便利そう - Qiita
UUIDは重複しないIDを生成する手段として便利ですが、特にversion4(乱数によるUUID)を利用する場合は一意性を得るのと同時に乱雑さも得ることになりますので、UUIDに順序性を求めることができません。 UUID - Wikipedia https://ja.wikipedia.org/wiki/UUID UUID（Universally Unique Identifier）とは、ソフトウェア上でオブジェクトを一意に識別するための識別子である。UUIDは128ビットの数値だが、十六進法による550e8400-e29b-41d4-a716-446655440000というような文字列による表現が使われることが多い。元来は分散システム上で統制なしに作成できる識別子として設計されており、したがって将来にわたって重複や偶然の一致が起こらない前提で用いることができる。 UUIDだと実現できない
PostgreSQLでの中間一致検索の性能改善 - Qiita
この記事はラクス Advent Calendar 2018の24日目です。 今年、仕事で取り組んだ中間一致検索機能の性能改善について書きたいと思います。 前提条件 かなり大量レコードを扱う中間一致検索処理の性能を改善したい 工数と納期の都合によりElasticSearchのようにシステム構成が変わるような大掛かりな変更はできない 同じ理由でデータベース本体のバージョンも避けたい（現状、PostgreSQL9.4を使用） yumでインストール出来て、カスタマイズが不要なものが好ましい 担当しているシステムの特性上、形態素解析は不向きなのでN-gramが前提 という制約のなか検討を行いました。 現状の実装 GINインデックス + tsvector/tsquery というPostgreSQLの標準機能を組み合わせてuni-gramなインデックスを実装をしていました。 かなりのレコード数までは高速
PHP: fgetcsvでもSJISのCSVをUTF-8として《安全》に読む方法(ストリームフィルタ使用) - Qiita
fgetcsvでShift-JIS文字コードのCSVを読むと、文字列がShift-JISのままの配列が返ってくるため、UTF-8を基本的な文字コードに据えたシステムでただ不便というだけにとどまらず、SJISのCSVをfgetcsvで直接読み取るのは「5C問題」のため危険である。 本稿では、ストリームフィルタを使ったSJIS CSVの安全な読み込み方法を紹介する。なお、本稿で作るストリームフィルタの完成形はGitHubで公開する。 5C問題とは よく見かける次のような実装は5C問題のため、データによっては読めないものが出てくる危険性がある: $fp = fopen('sjis.csv', 'r'); while ($row = fgetcsv($fp) !== false) { // fgetcsvで読み取った後に、文字コードを変換している mb_convert_variables('UTF
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cakes（ケイクス）
