暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
![暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e47047d889cfd3ce7f760f210e3636aa3d4268c0/height=288;version=1;width=512/https%3A%2F%2Fimage.nanapi.com%2Fr%2F2014%2F06%2F03%2F14%2F20140603144910_538d61d62fbd4.jpg)
エンジニアの給与レベルがプロスポーツ化する日 - ワザノバ | wazanova
http://pando.com/2014/03/22/revealed-apple-and-googles-wage-fixing-cartel-involved-dozens-more-companies-over-one-million-employees/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 40分前 先ほど、ワザノバのアクセスランキングをつくっていて、「給与を上げるベストな仕組みの解がない」が意外に上位ランクに入ってました。我ながら振返ってみて、タイトルも内容もネガティブ過ぎたかなとちょっと反省してます。その時は、休日に家族をスキーに連れて行ったのですが、自分は滑らずにスタバで原稿を書いていたので、そのストレスだったかもしれません（笑） お伝えしたかったのは、 業界全体の「平均」給与レベルを
Heroku でマルチテナントな Rails アプリを実現する - present
はじめに Web アプリでマルチテナントをやる場合、 すべてのテーブルに tenant_id を追加してデータを分けるのではなく、 テナントごとにデータベースを分けたい。 データベースを分けておけば、バグで他のテナントのデータまで変更してしまう可能性を減らせる。 データベースを分けたマルチテナントをサポートする、 『Apartment』という gem を使った記事を以前書いた。 Heroku 上での運営を考えているので、 Heroku 上でもテナントごとにデータベースを分けたマルチテナントが可能か試してみた。 なお、Heroku Postgres を使うから、厳密にはテナントごとにスキーマを分けることになる。 Heroku にデプロイ Rails + Apartment でマルチテナントな Web サービスを作る - present で作成した Rails プロジェクトを使うことが前提。
UIとかUXとかに関してたまに思うこと - 愛と勇気と缶ビール
UIとかUXとかって、ユーザをおもてなしする、快適に使ってもらう、という意味ではもちろん大事な概念なのだろうが、要は「あってもなくてもいいものをとりあえず使ってもらって、そっからお金をもらう」というような所謂フリーミアム的なサービスを無意識に前提とした言葉な気がしている。 というのは、仕事上使わざるを得ないウェブアプリケーションや、あるいは止むに止まれぬ欲求によって使わざるをえないサイト（エロサイトとか）については、僕らは「ちっ、使いづらいクソUIだな」と文句を言いながらも、使うからである。 ある意味あってもなくてもいいような、ユーザにとって喫緊の用事はないが、サービス事業者側が将来お金を儲けるためにとりあえず使って欲しいようなサービスにおいて、UIとかUXとかが問題になる。なんの役に立つか分からない上に使いにくいサービスとか、意味不明だからである。 つまり、UIがどうとか、UXがどうとか
CoffeeScript: 配列の差分(diff)を取る一行の関数 - Qiita
list1 = ["green", "red", "blue", "red"] list2 = ["green", "yellow", "red"] # 独立した関数を定義する場合 diff = (list1, list2)-> (value for value in list1 when list2.indexOf(value) is -1) # prototypeを拡張する場合 Array::diff = (array)-> (value for value in this when array.indexOf(value) is -1) console.log diff(list1, list2) console.log list1.diff(list2)
jQuery の配列系のメソッドをメモしとこ
jQuery は機能が豊富なので、しばらく使わないと忘れてしまう。 ここでは、jQuery と配列の関係に絞って目的別に逆引きできるようにしておく。 配列から jQuery オブジェクトを作成 $ 関数に渡せばOK $([1,2,3]) NodeList のような配列っぽいものを渡しても解釈してくれる。 $(document.getElementsByTagName("div")) // $("div") と同じ ※内部的には setArray メソッドが呼ばれてるが、外から使うことは稀。 jQuery オブジェクトを配列のように扱う 要素数を取得する length プロパティを使えばOK。 $("div").length // document.getElementsByTagName("div").length と同じ jQuery のメソッドを使って操作する限りは、適切に lengt
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
JavaScriptのプロトタイプチェーン - Qiita
元ネタ:JavaScriptはいかにしてprototypeを捨てクラスベース継承を得るのか - なんたらノート第三期ベータ なんか色々突っ込みたかったので。 この人はプロトタイプチェーンでクラスベースの言語と同じことをやろうとしているのかな。 プロトタイプチェーンは、ただの道具 npm にあるほとんどのライブラリがチェーンを活かして作られてない理由が説明できない。 プロトタイプチェーンは、それ自体ただの道具です。ほとんどのライブラリで使われないと有用ではない、なんてことはないはずです。 そもそも、プロトタイプチェーンの仕組みは結構利用されています。気づいていないだけ、じゃないですかね。 メソッドとそれ以外のプロパティ ちょっとまって、JavaScript のプロトタイプチェーンの教科書でこの、n という初期化パラメータを持つオブジェクトの継承はどういうふうに実装したっけ?? プロトタイプチ
JavaScriptはいかにしてprototypeを捨てクラスベース継承を得るのか - なんたらノート第三期ベータ
きっかけは、prototype と constructor と __proto__ の関係を再確認していたときでした。JavaScriptはこうだけど、これって、AltJSな言語の継承はどうなってるんだろうと思って試したくなりました。 ちょっと気持ち的に、なんだか宗教に入ったみたいに俺は JavaScript がわかったって声高に言う人、だいたいみんな、プロトタイプチェーンによる移譲がクラスベースの継承に束縛されていた思考のブレイクスルーなんだぜ、みたいに言うんだけど、いったいそれがどれほど素晴らしいものなんだろうと考えてしまい... もしプロトタイプチェーンがそんなに素晴らしいんなら、npm にあるほとんどのライブラリがチェーンを活かして作られてない理由が説明できない。もしかしたら、仕組みがいくら面白くても、実際のメンタルモデルにフィットせず、実は使い物にならないんじゃないか ----
とりあえずひと通り知っておこう！2014年の気になる物を色々試してリニューアルしてみた制作の流れ！ | バンクーバーのうぇぶ屋
さて、先日バンクーバーな僕らをリニューアルしました。得に特別な事をしたわけでは無いのですが、ここ最近とにかく会社の事やらシェアハウスの事やらでテンヤワンヤしておりまして、自分の制作環境の話等を書いておらず、情報が昔のままになっていたので、今日はさっきまで色々試しながらこのサイトを作ってたという事もありますし、忘れない内に覚えてる範囲で備忘録的に書いておこうかと思います。 恐らく今後もどんどん変わっていくかと思いますし、まだまだ学び途中の物も沢山ありますが、まずは参考にした物も含め共有させて頂きます。去年書いた記事と比較しながら読むとちょっとは楽しめるんじゃないかと思います。 レスポンシブやらアイコンフォントやらフラットやら！2013年の気になる技術やデザインを試してみたリニューアル手順！ また、このブログでは何度か触れていますが、もはや僕はクライアントのために手を動かして何かを作るという事
続:スタートアップのCEOの役割 - sudoken Blog
スタートアップのCEOの役割 - sudoken Blog というエントリーを書いてから約9ヶ月が経ちました。 前回はシードラウンドからシリーズAに向かっていく手前を書きました。 その続編ということで、シリーズAからポストシリーズAのCEOの役割の変化を振り返ってみたいと思います。 ちなみに前回のサマリー とにかく最初のステージでは、営業・採用・PR・資金調達の4つにシンプルにフォーカスしてました。 12月 実は、この時期に僕の中でシード後に達成したい目的は、ほとんど達成していました。 自分達のミニマムな事業構造がどのように成立するかを最初の試金石においてました。 ・きちんと売れるのか？ ・きちんと収益が出るのか？ ・きちんと効果が出るのか？ この3つの問いについての粗々の回答を自分の中で実感値を持って掴むことが出来たのが11月の後半です。 そこで、この辺から資金調達に動きはじめます。 何
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.monoweb.info/blog/2014/08/07/zram/