Writing a storage engine in Rust: Writing a persistent BTree (Part 1)
As part of a recent personal journey to better understand databases and better learn Rust, I have recently took on the project of writing a simple key-value storage engine. Crazy, right? Lets get started! B-Trees vs LSM TreesThe first thing one must think of when writing a key-value storage engine is -”How should I store my data so that I can perform reads and writes efficiently?”; The two most co
明日から使える実践エラーハンドリング
class: center, middle # 明日から使える<br/><strong>実践</strong><br/>エラーハンドリング Scala関西Summit 2018 11/10 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value 代表取締役 * Opt Technologies 技術顧問 <img src="../images/opt_logo_1.jpg" alt="Opt Technologies" width="450" style="margin-left: 0px" /> * F-CODE CTO <img src="../images/f-code_logo.png" alt="f-cod
4歳娘「パパ、具体的な名前をつけないで？」 - Qiita
↓新作もよろしくやで！ ジェネリクスをもう少しだけ使いこなす。 コロナウィルス対策でリモートワークしてみたらReduxやVuexのメリットが分かった 36歳ザコーダーの休日 ワイ「何やこのコード、全然動かへんやん」 ワイ「怖いな～怖いな～…なんか嫌だなあ～」 よめ太郎「（何で自分が書いたコード見て稲川淳二みたいに怯えとんねん・・・）」 よめ太郎「（そんな鳥肌立つようなクソコード書いてんのかいな・・・）」 娘（4歳）「ねぇ、パパ」 ワイ「なんや、娘ちゃん」 娘「ちょっと、作ってほしい関数があるの」 ワイ「またかいな」 ワイ「娘ちゃんはホンマに関数が大好きやなぁ」 ワイ「しゃあない、パパはプログラミング苦手やけど、頑張って作ったるわ」 娘「ありがとう、パパ」 今回の要件 ワイ「ほんで、今回はどんな関数を作ればええんや？」 娘「えっとね」 娘「'あ'という文字列を渡したら」 娘「['あ', 'あ
良いコードの書き方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 チームによる継続的開発を前提としたコーディングのガイドライン。 特定の言語を対象としたものではないが、主に静的型付けのオブジェクト指向言語を想定している。 サンプルコードは別段の定めがなければSwiftで記載。 ガイドラインの目的 生産性を高め、メンテナンスコストを下げる バグが生まれづらくする 開発メンバー（特に新規参加者）がコードを理解しやすくする 初心者プログラマーの教育 内容の説明 タイトルの頭についた【数字】は重要度。 高いほどシステムに与える影響が大きいが、低いものの方が影響が小さく改修しやすいものが多い。 【5】変数
【サーバーレス】18,570本のブログの形態素分析をやってみた | DevelopersIO
こんにちは！コンサルティング部のキムです。 私は韓国で昔から「晴れ男」によく呼ばれましたけど、東京来てからはあまり晴れた日が少なかった気がします。 ですが、直近の天気は良さすぎて毎日ハイパーになっています。さすがに東京の空は綺麗ですね！（韓国の空は微細ホコリのせいで綺麗な日が少ないです） あ、「晴れ男」や「晴れ女」という表現は韓国語ではないものですが、面白いし、とても良い表現だと思います :D さて、今日は先日小規模で試してみた「Developers.IO ブログで日本語の辞書を作ってみた」の内容をDevelopersIOブログの全体の規模で実装してみましたので、そのお話をしたいと思いました。 さすがにある程度の規模では小規模とは異なり、考えすべきなことがたくさんありました。こんなに簡単な作業（1つのLambda関数実行）を大規模で実装しながら私がハマったこと・わかったことを本記事にて纏め
コードの可読性についてのプレゼンテーション紹介 vol. 1: "導入と原則" 編
はじめに こんにちは。コミュニケーションアプリ「LINE」の Android クライアントチームの石川です。 先日、コードの可読性についてのプレゼンテーション (https://speakerdeck.com/munetoshi/code-readability) を公開しました。 今後、このプレゼンテーションについてのちょっとした解説を、本ブログ上で不定期に連載していきます。 今回は、このプレゼンテーションの概要と、最初の章 "導入と原則" についての解説を行います。 このプレゼンテーションについて このプレゼンテーションは、コードの可読性を向上するためのアイディアをまとめたもので、以下の8つの章からなります。 導入と原則: 可読性の高いコードの重要性、プログラミング原則 命名: 名前の示す内容、文法、語の選択 コメント: ドキュメンテーション、インラインコメント 状態: 状態遷移の管理
コーディング面接対策のために解きたいLeetCode 60問
自分がコーディング面接対策のために解いてよかった LeetCode の問題をコンセプトごとにまとめました。カバーするコンセプトは LinkedList Stack Heap, PriorityQueue HashMap Graph, BFS, DFS Tree, BT, BST Sort Dynamic Programming Binary search Recursion Sliding window Greedy + Backtracking です。 これらの問題が 30 分以内に実装できれば面接の準備は整ったと言っていいと思います。Easy と Medium で問題は構成されてます。進捗を管理するためにGoogle Spreadsheetを用意しました。コピペしてご自由にお使いください。 これらの問題は、LeetCode のリスト機能でも公開されています。クローンすれば自分がすでにど
RFC 2094 (non-lexical lifetime) の非公式訳 | ubnt-intrepid's blog
本記事は Rust Internal Advent Calendar 2017 第1日目の記事です． 今年の 9/30 に採択された non-lexical lifetimes の RFC である RFC 2094 の非公式訳です． Feature Name: (fill me in with a unique ident, my_awesome_feature)Start Date: 2017-08-02RFC PR: https://github.com/rust-lang/rfcs/pull/2094Rust Issue: https://github.com/rust-lang/rust/issues/44928概要Rust の借用システムにおける，ノンレキシカル・ライフタイム （レキシカルスコープではなく制御フローグラフに基づくライフタイム）対応への拡張．本 RFC では，この新
Programming WebAssembly with Rust — The Book!! – Kevin Hoffman – Medium
Rust and WebAssemblyThose of you who follow my rantings and ravings on Twitter may have noticed a trend lately. I’ve been retweeting and posting a bit about WebAssembly, in addition to my usual programming language posts. I’ve also been hinting at the idea that I may or may not be working on a top secret project beneath my secret island lair in Northern Connecticut. At long last, the Interagency C
30代から始めるwebフロントエンド入門 - Speaker Deck
Transcript 30代から始めるwebフロントエンド入門 コネヒトマルシェ #2〜webフロントエンド市〜 @itosho 1 ▪ 自己紹介 ・伊藤 翔 / @itosho ・所属：コネヒト株式会社 / Supership株式会社 ・野球とアイドルが好きです。 ・最近のオススメ：sora tob sakana 先日メジャーデビュー ▪ 自己紹介 ・伊藤 翔 / @itosho ・所属：コネヒト株式会社 / Supership株式会社 ・野球とアイドルが好きです。 ・最近のオススメ：sora tob sakana 先日メジャーデビュー ・主にサーバーサイドエンジニアをやっています。 ・よく書く言語：PHP / Ruby / Golang ＿人人人人人人人人人人人人人人＿ ＞ サーバーサイドエンジニア ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣ 4 ▪ 今日話すこと
［Unite 2018］誘導ミサイルはどうやって作るのか？ 基礎からCompute Shaderによる実装まで
［Unite 2018］誘導ミサイルはどうやって作るのか？ 基礎からCompute Shaderによる実装まで 2018年5月7日から3日間にわたって東京国際フォーラムで「Unite Tokyo 2018」が開催された。初日となる7日は基調講演だけだったが，8日と9日が終日専門セッションとなっていた。ここでは8日のユニティ・テクノロジーズ・ジャパン エンジニアの安原祐二氏の講演を紹介してみよう。 安原氏はかつてPlayStationで3Dスペースシューティング「オメガブースト」を作った人だ。……と聞いて「つまり神プログラマですね」と理解してもらえるかどうかは昨今では微妙だが，初代PlayStationの限界を超えるようなゲームを作った人であり，毎年Uniteでは「非力なマシンで軽々動いてるけどこれ本当にUnity？」と言いたくなるようなデモを披露している。 今年の演題は「誘導ミサイル完全マ
数式を綺麗にプログラミングするコツ #spro2013
[Yang, Downey and Boyd-Graber 2015] Efficient Methods for Incorporating Knowl...
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
マーチン・ファウラー氏「リファクタリング 2nd Edition」で20年ぶり内容刷新、サンプルコードはJavaScriptに。Web主体で書籍はエッセンシャル版の位置づけ
マーチン・ファウラー氏「リファクタリング 2nd Edition」で20年ぶり内容刷新、サンプルコードはJavaScriptに。Web主体で書籍はエッセンシャル版の位置づけ マーチン・ファウラー氏が20年ぶりに大幅に内容を刷新した書籍「リファクタリング 2nd Edition」を今年秋に出版する計画だ。サンプルコードはJavaからJavaScriptに変わる。また、コンテンツ本体はWebサイトとなり、書籍はそのエッセンシャル版の位置づけとなる。 「リファクタリング」とは、ソフトウェアの機能追加や変更、性能向上などに備えるため、開発されたコードの外部に対する振る舞いは変更せず、より整理された、あるいは洗練されたコードに書き換えること、あるいはその手法のことを指します。 いまでは開発者の間で広く知られているこのリファクタリングについて、その目的や手法などを書籍としてまとめあげ、出版したことで啓
ロギングにおける十戒 | Yakst
どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho
ずっと前から積ん読状態だった「SQLアンチパターン」を読みました。 何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいい本ですねー。もっと早く読むべきだった。— @ketancho (@ketancho) 2018年3月6日 噂通りとても良い本で、まさに「エンジニアとしての血肉本」と言えます。1, 2年目の頃に読んでおくべきだったなーと少し後悔しています。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾と
【20選】俺が唸ったOSS・GitHubリポジトリ！Web企業で働くエンジニア達に聞きました - エンジニアHub｜Webエンジニアのキャリアを考える！
【20選】俺が唸ったOSS・GitHubリポジトリ！Web企業で働くエンジニア達に聞きました さまざまな企業のエンジニア20人に、リポジトリの中から「これは素晴らしい」「他のエンジニアにもぜひ使ってほしい」と思うものを紹介してもらいました！ GitHub上に存在するリポジトリや、その他の場所に存在するものまで、オープンソースソフトウェア（以下、OSS）は世の中に星の数ほど存在します。利便性の高さから世界中の開発者が利用していますが、反面その種類の多さから、どれを使ったらいいのかわからないという方もいるでしょう。 そこで本企画では、企業のエンジニア20人に、さまざまなリポジトリの中から「これは素晴らしい」「他のエンジニアにもぜひ使ってほしい」と思うものを紹介してもらい、その理由を解説していただきました。 使って便利なだけでなく、コードを読んで技術研鑽に活用するもよし。ぜひご一読あれ。 ※各カ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AST explorer
今あえてDRY原則に向き合う
