http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
http://yapcasia.org/2014/talk/show/b49cc53a-027b-11e4-9357-07b16aeab6a4
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース(OSS)を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
Comfortable C3 makes it easy to generate D3-based charts by wrapping the code required to construct the entire chart. We don't need to write D3 code any more. Customizable C3 gives some classes to each element when generating, so you can define a custom style by the class and it's possible to extend the structure directly by D3. Controllable C3 provides a variety of APIs and callbacks to access th
Go For Perl Mongers (or, for Lightweight Language lovers) Daisuke Maki Engineer, LINE Corporation Who Is This Guy? @lestrrat LINE / Japan Perl Association / YAPC::Asia (2008~2013) STF / peco (new!) 2 俺とGo Goしてみて約1年弱 概算10~12万行くらい書いた。lived○○rBl○g の裏方にもこっそりgo入れてる 最初の4万行くらいまでに goの落とし穴にほぼ全て落ちた 自信がある 今日はその落とし穴から学んだ諸々の話 3 対象観客層 もともとPerl/Python/Ruby/PHPあたりから来た人 Goは最低限とりあえずかじった程度はやった人 かじってみたけど「Go、便利そうだけどなん
Video: https://www.youtube.com/watch?v=LaxbdIyBkL0 Presented at at the Google WebPerf Special (London WebPerf Group), August 26th 2014. Efficient JavaScript webapps need to be fluid and fast. Any app with significant user interaction needs to consider how to effectively keep memory usage down because if too much is consumed, a page might be killed, forcing the user to reload it and cry in a corner
This talk is about how to use browserify to develop front-end modular code using Common.JS, and how those modules should be documented, designed, and released using an automated build system. In order to explain these concepts I'll walk you through a few of my own open-source creations, highlighting interesting points as we go along.
Web サービスの会社にはイケイケなサービスの陰に隠れて、かつてイケイケだったけど今はイケテナイサービス、とか、ぶっちゃけ最初っからあんまりやる気なかった☆サービス、これどこで拾ってきちゃったのサービス、などなど、惰性で続いちゃってるようなサービスがごろごろあったりします。 そういうイケテナイサービス群はメンテナンスの手間を取らせる物なので、エンジニアとしては閉じてしまいたい。でも非エンジニアとしては閉じたくない。いや、本当は閉じたい!でもちょっとは儲かってるし、閉じるとわずかながら存在するユーザーからクレームくるし、連携先の企業とやりとりするのめんどいし、まあいろいろめんどうそう。 そこで、「イケテナイサービスにはできる限りメンテナンスの手間を払うな」という話がエンジニアのとこにきて「お前なーっ!そのメンテナンスの手間がなーっ!」となり、話がループを始めます。なぜこういう噛み合わない話に
インフラストラクチャー部の成田(@mirakui)です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか? ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド本体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く