pixiv小説縦書き機能 開発の裏側 ～横のものを縦にする～ - pixiv inside [archive]
はじめましてこんにちは。pixivでアルバイトをしているhakatashiです。 さる6月10日、パソコン版pixiv小説にて縦書き表示機能がリリースされました。この開発のあらかたを担当したので、今回の縦書き機能開発における裏側を紹介いたします。 構想 縦書き機能開発にあたり、設計段階からその大部分を一任されました。小説機能開発において自分の中に絶えず理念として存在していたのは、ユーザーに最高の読書体験を提供することです。縦書きによって得られる利益を最大化し、快適な閲覧を支援するために、以下のような構想を置きました。 縦書き横書きの組版の差異における違和感を可能な限り軽減すること。 スクロールとページングを融合した、柔軟で快適な閲覧インターフェイスを提供すること。 この2点について詳しく解説します。 縦組版 まず、ウェブブラウザで縦書き表示を実現するにあたり、どのような手法をとるかという問
![pixiv小説縦書き機能 開発の裏側 ～横のものを縦にする～ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8cb8c8e15c630ee29bd00c32234b431a93a2053d/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhakatashi%2F20150615%2F20150615155753.png)
grepでログ解析をするなんてひどい話だ | POSTD
今でも、 systemdのjournal におけるバイナリのストレージフォーマットに関して、不満を漏らす人が多くいることに私は驚きを隠せません。私は長年、システム管理者として働いてきており、1年以上も syslog-ng の オープンソースエディションのメンテナ として活動してきました。だからこそ、テキストではないストレージフォーマットに対して、なぜ多くの人が批判的なのか、私は理解に苦しんでいます。更に、反論を唱える人までいることが信じられません。もしかしたら、私は別世界の人間なのかもしれません。ですが、より良い選択肢があるのに、テキストのストレージを使う理由はほとんどありません。ロギングをする必要性、そしてなぜ、テキストのログストレージに対してそこまで用心深いのかについて、私は何度も尋ねられました。ここに、私が導き出した答えを紹介したいと思います。 これは、journalについて弁明する
500マイル以上離れた場所にメールが送れないのだが
http://web.mit.edu/jemorris/humor/500-miles From: Trey Harris <trey@sage.org> 今から私が書く話は、起こりようのない問題についてだ。この話を広く一般に公開してしまうのは惜しい。というのも、いい酒の話のネタになるからだ。この物語は、退屈な詳細や問題を隠すために、多少事実を変えていて、物語を面白く脚色している。 数年前、私はキャンパスのメールシステムを保守する仕事をしていて、統計学部の学部長から電話を受けた。 「大学の外にメールを送るのに不具合が発生しているのだが」 「どんな問題でしょう？」と私はたずねた。 「500マイル以上メールを送れないのだよ」と学部長は説明した。 私はラテを吹き出した。「何だって？」 「ここから500マイル以上離れた場所にメールを送信できないのだよ」と学部長は繰り返した。「実際は、もう少しあるの
CPU実験で自作CPUにUNIXライクOS (xv6) を移植した話 - 豆腐の豆腐和え
今年のCPU実験では、有志からなる我らがX班が、おそらくCPU実験史上初である自作CPUへのOS (xv6) 移植に成功しました。コア係とコンパイラ係の面々がそれぞれまとめ記事を書いていたので、OS係から見たOS移植のまとめも書こうかなと思います。こんなことしてましたってことが伝わればいいなと思います。 この記事を読む後輩やらなんやらがいたら、ぜひ僕らがやったようなことはさっさとクリアしちゃって、さらにさらに面白いことをする踏み台にしていってほしいですね。 どなたが読んでもある程度概要が伝わるよう、まずCPU実験とは何かということをさらっと書いた後、実際にxv6を移植するにあたってやったことをまとめたいと思います。 CPU実験とは CPU実験は僕の学科（理学部情報科学科）で3年冬に行われる、半年間にわたる学科名物演習です。 最初の週で4～5人程度の班に分けられた後、それぞれの班でオリジナル
知らぬはエンジニアの恥。今さら聞けない【コンテナ/仮想化技術】11選 - paiza times
Photo by Sam MacCutchan どうも後藤です！ もう10年以上になるでしょうか･･･ とにかくなんでもかんでも仮想化すればよいというこの風潮。paizaでも仮想化技術は大活躍中。インフラは仮想化技術の上に構築されているし、もちろんコードの評価環境だってばりばりの仮想環境上です。仮想環境ばっちこーい！ いったいいつからこんな流れになったんでしょう？どこに基準を求めるかでだいぶかわりますけれども、執筆現在から考えると、こうした流れには35年くらいの歴史があります。使われる仮想化技術は時代とともにかわってきました。だいたいどの時代にも流行ってものがありました。 最近（2014年ごろ）の流行とえば、インフラの一番下にハイパーバイザを入れて、その上でDockerを動かして、管理にはChefやPuppetを使うといったものです。数年経てば状況は変わるでしょうけれども、とにかく楽をした
「Virtualを仮想と誤訳した責任は我々にあります」 - Plan9日記
書籍「ソフトを他人に作らせる日本、自分で作る米国」を読んでいたところ、元日本IBMの方によるタイトルの発言が飛び出した。この業界に長くいると、仮想記憶に仮想計算機と「仮想」という訳語にはまったく違和感を感じなくなってしまったが。。。曰く、IBMがVirtual memoryを発表したとき（MVSのことかな*1）、日本IBMが仮想記憶と訳したのだそうな。『virtualは「事実上の」「実質的」という意味であり、virtual memoryは「本来のメモリーではないが事実上メモリーとして使える技術」を意味する。』 大学時代の恩師も次のように言っていた。 「仮想」という概念が、コンピュータの世界に入ったのは、１９７５１９６５年のことである。MITがMULTICSという汎用大型TSSの構想を発表した。これが現在の、パソコンネットワーク時代の幕開けの狼煙であった。この中の技術に「仮想記憶」の概念が含
俺の被害妄想でrailsが死ぬ時 - komagataのブログ
昨日EdTech Hackathonに行って久しぶりに色々なWeb関係の方の空気に触れて思った事。 俺はrails好きで強力だし楽しいなーと思うんだけど、 「GoogleからJSのシングルページでもSEO的にペナルティが全く無くなったらサーバーサイド要らねんじゃね？mBaaSで良くね？」 とか 「ちょっとしたサーバーサイドの処理はPHPで良くね？エンジニア多いし、安いし、技術的負債とかセキュリティ・ホールとか経営者からしたらたいして気にならないし、実際の所よくわからないし、来年どうなってるかわからんし。」 とか 「railsエンジニアとか単価高い割に何やってるのかわからないし。テストを書いてます？もっとこうガーッと派手に動く機能追加してくれねえかなあ？」 とか 「長期的なプラットフォームとかはガッツリ作ってくれて構わないけど、もっと雑でいいから短命のモバイル・アプリ量産してくれねえかな？」
ちぎれた海底ケーブルはどう直す--保守船「KDDIオーシャンリンク」の役割とは
KDDIは7月19日、海底ケーブル保守船「KDDIオーシャンリンク」の報道陣向け見学会を開催した。KDDIオーシャンリンクは海底ケーブルの敷設・保守船として1992年に誕生。KDDIの100％子会社である国際ケーブル・シップが保有する2隻の保守船のうちの1隻だ。運行および船舶管理は商船三井グループのMOLケーブルシップが担当している。 日米をほぼ直線で接続する「Unity」など世界をつなぐKDDIの海底ケーブル ケーブルシップは現在、世界に40隻程度あるという。日本で民間保有のケーブルシップとしてはKCSが保有する2隻とNTTワールドエンジニアリングマリンの持つ1隻の合計3隻が存在している。見学会の冒頭では国際ケーブル・シップ 代表取締役社長 矢田部亮一氏から「我々が作業甲板と呼ぶ広い作業場には柱が1本もない。我が国が持っていた航空母艦を作る技術が活かされている。そうしたアナログなものから
データベースのスケーラビリティをどうやって向上させるか
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
ニコニコ大百科のアーキテクチャ - グニャラくんのグニャグニャ備忘録@はてな
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね（しんぱいそうなめでみている） http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、１台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
「解読不能は数学的に証明済み」、RSAを超える新暗号方式とは ― ＠IT
2008/04/11 すべての暗号はいずれ破られる。2000年前のシーザー暗号の時代から高度な暗号技術が一般化したデジタル通信の現代に至るまで、それが暗号通信の歴史が証明し続けた事実であると同時に、もっとも人口に膾炙したクリシェでもあった。例えば、鳴り物入りでリリースされたDVDのコンテンツ暗号技術「CSS」（Content Scramble System）が、リリースからわずか数年で10代のノルウェー人ハッカーに破られたことは記憶に新しい。 【追記】（2008年4月15日） この記事は取材に基づいて執筆したものですが、一部専門家らから「CAB方式暗号は解読不能」というのは誇大表現ではないかとの疑義が呈されています。アルゴリズムの公開や第三者による検証がない現在、この記事に登場するCAB方式が発案者・実装者の主張通り画期的な暗号方式で、本当に解読が不可能であるかどうか分かりません。現在、専
コンパイラの入り口、「字句解析」のための文字列操作
前回はBNFでプログラム言語S1sを定義しました。今回は、この定義に従って記述されたプログラムをコンパイルするに当たり、最初に実行する処理である字句解析について解説をします。 「字句解析」とは何ぞや？ 前回、プログラミング言語S1sを次のように定義しました。 <program> ::= main '{' <expression> '}' <expression> ::= <term>{ <opeas> <term> } <term> ::= <factor>{ <opemd> <factor> } <factor> ::= <number>|( <expression> ) <number> ::= <digit>{<digit>} <opeas> ::= + | - <opemd> ::= * | / <digit> ::= 0|1|2|3|4|5|6|7|8|9 この定義から、S1sの
DSAS開発者の部屋:GREEさんの勉強会の資料を公開しました
先日発表してきた、グリーさんの 第9回 オープンソーステクノロジー勉強会 『DSASのいろいろ』の発表資料と音声を公開しました。 発表資料 (PDF, 2,294 KB) 音声 (mp3, 32,151 KB) 発表はこんな内容です。 自己紹介 [0:22] (1) DSASの特徴の紹介 [6:34] 設計思想、全体構成など (2) DSASの構成要素の紹介 [17:22] ロードバランサ - LVS, keepalived [17:33] ネットワークブートの活用 [30:23] 故障に強いストレージサーバ - DRBD [37:15] NICの二重化 - bonding [44:29] シリアル接続 温故知新 [46:24] サーバリソースの見える化 - ganglia [49:11] 質疑応答 [58:00] 発表はかなり駆け足でしたが、 ロードバランサ (LVS, keepaliv
shell のちょっとしたテクニック - odz buffer
後輩が cat README | tr ' ' '\n' | sort | uniq -c | sort -nr | head てなテクニックを見て、びっくりしたみたいな話をしていたのだが、こういうパイプラインを利用するテクニックを学んでいないのは色々損な気がする。 ていうか、サーバで丸一日以上かかるような処理を実行するのもしょっちゅうなのに、GNU screen も nohup も知らないってのはいろいろ支障があるような気もするのだが、だれも教えないものかなぁ。 ということで、bash or zsh のちょっとしたテクニックとか*1。リダイレクトとかパイプラインは略。 連続実行 単純に連続実行。 % foo; barfoo が正常終了したときだけ bar を実行 % foo && barfoo が正常終了しなかったときだけ bar を実行 % foo || bar&&、||は本来は論理演
Happy Hacking！ 口笛でPCを操作しよう
ショートカットキーをちょっと覚えたくらいでハックだなんて口にしてはならない。優れたハッカーなら両手がふさがっていてもデバイスを操作するにはどうすればよいかを考える。ここでは、口笛によってメールチェックやウィンドウを操作し、作業効率を高めるハックを紹介しよう。 キーボード、マウスに続く入力デバイスとして期待されているのが、音声だ。しかし、従来の音声認識といえば、コンピュータのプロセッサに高い負荷を与える上、ユーザーの声質への依存度が高く効率が悪かった。 しかし、最近リリースされたsndpeekは、こうした問題を解決する。本記事で紹介されている強力なsndpeekは、最近の処理能力とアルゴリズムの進歩によって、エラーレートが低くユーザーに依存しない音声認識を実現しつつ、必要なプロセッサ負荷も抑えられている。実際の動作イメージはこちらの映像が詳しい。 このsndpeekプログラムは、マイクからの
Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
