LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog
LINE Engineering Blog official account
今年はさだまさしさんのデビュー40周年という記念の年ですね。大平です。さだまさしさんの歌は、時に切り口鋭く、時に叙情的に情景を描写する技術もさることながら、落研出身ゆえの話術の巧みさ、流暢さも魅力の一つです。 あまりさだまさしの話を続けると上長に叱られますので、、この記事では「流暢な」という意味の名前を持つOSSのミドルウェアについて、ご紹介をしたいと思います。 fluentdについて fluentdは、Treasure Data Inc.の古橋貞之さんが公開しているOSSです。古橋さんはMessagePackの作者としても有名ですね。 fluentdは、古橋さんのブログ記事から説明を引用すると以下のようなツールです。 fluent は syslogd のようなツールで、イベントログの転送や集約をするためのコンパクトなツールです。 ただ syslogd とは異なり、ログメッセージに テキストではなく JSON オブジェクト を使います。また プラグインアーキテクチャ を採用しており、ログの入力元や出力先を簡単に追加できます。http://d.hatena.ne.jp/viver/20
NAVER UITのSass Mixins職人（他称）の上村です。 今日はLess & Sass Advent calendar 2011の21日目です。 3日目に書かれている通り、NAVERでは半年ほど前から実務でSassを使っています。今回は弊社で使用しているSassのディレクトリ/ファイル構成やMixinsについて解説します。 基本ディレクトリ/ファイル構成 今のところcss/sassディレクトリは下記のような構成を基本としています。 project |~css/ | |-category-A_TRUNK.css | `-category-B_TRUNK.css |~sass/ |~core/ | |-_setting.scss | |-_style-mixin-base.scss | |-_style-mixin-layout.scss | |-_style-mixin-module.scss | |-_style-mixin-reset.scss | |-_utilit
LINE Engineer
こんにちは、NAVER UIT つしまです。Less & Sass Advent calendar 2011の8日目です。 これまでのAdvent calendarの記事で、SassやLessの概要、活用法などが見えてきました。今回は、「Lessは機能不十分そうだし、Sassオシ多いし、Sassを使いはじめようかな・・」と思っている方に向けてはじめてのCSSメタ言語はLessがおすすめというおはなしです。 Lessって？ 既にCSSとフレームワークとメタ言語(2日目記事)やLESS初心者向けのナニカ(4日目記事)でも紹介があったとおり、LessはCSSを記述するためのメタ言語です。 ただ後発であるにも関わらず、SassにあるのにLessにない機能は結構あって、例えば、ifやforなどの制御文、extendが使用できなかったり、cssへの出力形式がSassほど選べなかったり・・ドキュメントもSassに比べれば少ないし・・もうSassにしよう・・ となりがちです。 Lessがおすすめな理由 それでもSassではなく、Lessをおすすめしたくなる理由があるんです。 Mixinの定義が
こんにちは。年末の予定はぶっ通しでスカイリムにつぎ込むことが決定したUIT富田です。 今回は、Less & Sass Advent calendar 2011の6日目として、sassのfunctionについて解説します。 すっぽりハマった四則演算の落とし穴 sassは値の四則演算をサポートしており、10進数だけでなく、16進数の値であってもよしなに計算してくれます。 color: #a3a4a5 + #111111; ↓ color: #b4b5b6; 16進数と10進数でもエラーにならず計算してくれます。（普通あまりやらないとは思いますが） color1: #000000 + 1; color2: #000000 + 15; ↓ color1: #010101; color2: #0f0f0f; この16進数の計算は、結果が#fffffを上回った場合、上回った分は切り捨てて、すべて#ffffffとして計算します color: #999 + #fff; ↓ color: #ffffff; 上記の例では、切り捨ててくれてありがとう、という感じですが、
はじめましての tacamy です。さて今日は Less & Sass Advent calendar 2011 の 3 日目です。 「Sass かぁ。まーたしかに便利そうだけど、実務で使えるか分からないし自分には関係ないかな。」 とか思ってませんか・・・！？ぜんぜんそんなことないですよ！( ･`ω･´) その証拠に、NAVER では半年ほど前から、新規サービスはすべて Sass を使って制作していますが、問題なく使えています。むしろ効率化できて、CSS を書く工数が減った気もします（個人の感想です）。 小難しいテクニックは、このあとの 22 人が書いてくれると思うの で（丸投げ）、今日の記事では、Sass を実務で使うことに絞って書いてみます。 実務でSassを使うメリットって？ 制作の工数が減る CSS3 を使うときのベンダープリフィックスをいちいち自力でつけたり、Clearfix や 画像置換の長ったらしいコードを毎回書いたり。そういう CSS を書く上での面倒なことは Sass におまかせすれば工数削減できます。 運用が楽になる ネストで書いていく
こんにちは。検索サービス開発４チームでメッセージアプリのLINEのiPhoneアプリ開発を担当している金泰敬(キム テギョン)です。 今回説明させて頂きたい主題はLINEのモデル側を支えているCore Dataです。Core Dataは、MacOS XのベースFrameworkであるCocoaのMVC構造のうち、Model側を担当しているFrameworkです。 Core Dataを利用するとデータモデルの設計、オブジェクトのデータの読み取り、書き込み、管理などを簡単に行うことができます。現在、LINEではCore Dataを利用してメッセージ、トーク、グループ、ユーザーなどを管理しています。 例えば、相手のメッセージが到着するとまずコアのデータからSqliteDBに格納します。そして保存されたメッセージに関連しているトークでも更新が行われます。もしそのメッセージが現在見ているトークと関連がある場合は画面上で自動的にメッセージが更新されます。 これらのすべての作業をする為に長いコードは必要ありません。iPhoneで再設計されたCore Dataのクラスを利用すれば簡単に実装することがで
こんにちは、NAVER Japan 検索サービス開発１チームで開発を担当している金森です。先日「NAVER まとめ」にトピック機能を追加しましたが、そのタイミングでまとめサービス内で使用しているサジェスト検索機能のリプレイスを行いました。今回このブログでは、実装したサジェスト検索の仕組みと、日本語入力ならではの諸々の面倒くさい問題とその対応について紹介したいと思います。 目次 まとめにおけるサジェスト検索 使用した技術 全体的な検索の流れ サジェストのためのローマ字変換 拗音のローマ字変換 入力途中の文字 「いんてｒねｔ」の対応 ローマ字変換のまとめ その他注釈など まとめ 今後の課題 1. まとめにおけるサジェスト検索 サジェスト検索は皆さんお馴染みのとおりの機能で、簡 単に言うと「検索語の入力中に検索候補が表示されるもの」と言えるかと思います。 まとめサービスでは、Web版の画面上部の検索窓や、iPhoneやAndroidなどのスマートフォン向けアプリの検索画面などでサジェスト検索を提供しています。また、「トピック」と呼ばれる、まとめを自由にカテゴライズできるメタタグ情報の入
こんにちは、QAチームのアベです。 iOS SDK でのコーディングって楽しいですよね。でも完成度の高いアプリを目指すと開発ライフサイクルの中でいくつものテストを充分に行う必要があり大変なことも多いです。難しいのは「充分に」というところです。何をもって「充分」といえるでしょうか？時間とお金があればいくらでもテストするよ！と思うものですが、時間とお金が潤沢にあるプロジェクトは現実にありません。 そこでコストと納期とのトレードオフで重要なところを重点的にテストするという戦略があります。 masuidrive さんも言ってました、「モデルの UnitTest は書く、Integration はあきらめよう」と。戦略は様々ですが比較的テストコードを書き易いモデルレイヤのプロダクトコードに対するユニットテストを充分に行うというのが現実的のようです。 本記事ではモデルレイヤにあるようなコードのユニットテストの充分さ（カッコ良く「充当性」と呼びます）を測る方法を考えてみます。必要なのは SenTestingKit と gcov す。前者は Xcode に標準で含まれているので説明はいらないでし
こんにちは。開発チームの駒津です。 ここ半年ほど、弊社アプリLINEのAndroid版を開発しています。関係者一同の頑張りもあってAndroidユーザー 100万人達成という非常にうれしい状況なのですが、かなりのハイスピードで開発が進みましたのであまり冒険せずに、力技で少し泥臭く実装している箇所もあります。 データベース周りも普通にSQLiteDatabase経由でSQL文を書いているのですが、できればOR Mapperを使いたかった... という反省点があり、現在開発状況が少し落ち着いた (のか...? 本当に...?) 今のうちにそっち方面を調べておこうかと思います。 Androidではそのスペックの都合上, 軽く動作するOR Mapperが向いていそうです。そういう視点で色々探して見たところORMLiteが良さそうな気がしました。正式にAndroidに対応していると謳っているのも嬉しいところ。 ORMLiteの他にはActiveAndroidというActiveRecord系のものがありました。Ruby on Railsの経験が長かった私は結構興味を持ったのですがオープンソースでは
自己紹介 ネイバージャパンのUIT(User Interface Technology)チームの裵完理(ベワニ)です。 概要 CSSやJavaScriptを使って複雑なデザインや動的なページを実装しているサービスが増えてきていますが、速度低下などの問題が発生しやすくなっています。これを100%直すことは難しいですが、改善するにはブラウザレンダリングプロセスを理解する必要がありますので、理解した上で改善方法を探してみましょう。 ブラウザレンダリングプロセスの理解 ブラウザの基本構造 User Interface - アドレスバー、戻る・進むボタン、ブックマークメニューなど、メインウィンドウに表示(document)されるページ以外の部分 Browser Engine - UIとレンダリングエンジン間のアクションを制御するもの Rendering Engine - リクエストしたコンテンツを表示させるもの。例えばコンテンツがHTMLの場合、HTMLとCSSをパースして表示させる。 Networking - HTTPリクエストのようなネットワーク通信機能を担当 UI Backend -
