タグ

2015年10月6日のブックマーク (13件)

  • 運転中の眠気をふっとばす方法 - ちるろぐ

    * 長時間のドライブをしてると強烈な眠気が襲ってくることってありますよね。 今日はそんな眠気を一発で吹き飛ばす裏ワザをご紹介しようと思います。 この方法は、長距離トラックのベテラン運転手さんから教えてもらい、とても重宝しています。 また、運転に限らず、授業中や会議中など、どんな場面にも応用可能ですので、ぜひ試してみてくださいね。 https://www.pakutaso.com 眠気をふっとばす方法 念のため言っておきますが、運転中に眠くなったときに、もっとも安全で確実な方法は、駐車して寝ることです。 これはもう当たり前なんですが、僕がお役立ち情報をシェアすると、たまにそんな的外れな指摘をしてくる頓珍漢がいます。 繰り返しますが、 運転中に眠くなったときは、駐車して寝るのが最善ですよ。 眠気をふっとばす方法 さあ、はじめましょう。眠気を一発で吹き飛ばす方法とは… 息を止めることです! 坂

    運転中の眠気をふっとばす方法 - ちるろぐ
  • Webサービスの作り方をプログラミング初心者が勉強した記録記事

    近年、よりプログラミング言語習得の注目度が上昇しています。 インターネット上でプログラミングが学べるサービスも多数登場していますが、いざ勉強を始めてみると難しいと感じたり、興味はあるけれど敷居が高いと感じてしまうこともあります。 今回は、未経験者や経験の浅い著者がプログラミングを学んだ成果を記録している記事をご紹介します。 プログラミングをこれから学習する方にとって参考になる内容となっていますので、ぜひ目を通してみてください。 未経験者がWebサービスの作り方を学んで成果を記録した記事 1.ノンプログラマーが3ヶ月でWebサービスを作ってみた|Qiita http://qiita.com/tabbyz/items/6513e84f319843c316d5 プログラミング関連の知識を記録、共有するサービスQiita内の記事です。 ノンプログラマー趣味でたまにプログラミングをする程度という筆

    Webサービスの作り方をプログラミング初心者が勉強した記録記事
  • 日本のソフトウェアエンジニア出身の創業社長まとめ - 表参道フォークウヱル別館

    IT業界で何かにつけよく言及されるのが、「アメリカでは Microsoft のビル・ゲイツ、Google のブリンとペイジ、Facebook のザッカーバーグを始めとするエンジニア出身のスーパースター起業家がゴロゴロいるのに、日ではほとんど見かけない」ということ。それが日IT業界が今ひとつパッとせず、欧米勢にやられっぱなしの大きな原因のひとつのように言われています。 また成功して富と名声を手に入れたエンジニアが多いことが、アメリカでのエンジニアの社会的地位や待遇を押し上げていることも事実であり、物価の違いはあれどコンピューターサイエンス専攻の新卒学生がいきなり年収15万ドルを提示される土壌になっているのでしょう。 しかし日でもハードウェアの領域に目を向けると、有名なところではホンダの田宗一郎やソニーの盛田昭夫・井深大のような例はけっこうあります。やはり問題はソフトウェア領域

    日本のソフトウェアエンジニア出身の創業社長まとめ - 表参道フォークウヱル別館
  • あなたのおっしゃるレビューってどのことかしら? - Qiita

    ソフトウェアのレビュー ソフトウェアの開発において、レビューが品質の確保をするために有効であることは私達は直感的、経験的に理解しています。 人は間違いを犯しますし、間違った人よりも他人のほうが誤りを見つけ易いものです。 ここまでは、認識を共通できるものでしょう。 しかし、レビューと一言で言った場合に、その実態にかなりのギャップが生じます。 ある人にとっては、気の合う同僚とコーヒーでも飲みながら成果物をチェックしてもらう事かもしれません。 しかし、別の人にとっては会議室で衆目の前で細かい所を吊るし上げられる苦行のことかもしれません。 ある人にとっては、口で簡単に説明するだけかもしれませんし、メールやツールでコメントを書くだけかもしれません。 しかし、別の人にとっては、準備の為に大量の資料を作り、終わった後にも大量の報告書を書く事かもしれません。 プロジェクトを初めて、レビューといった場合、

    あなたのおっしゃるレビューってどのことかしら? - Qiita
  • Railsで昨今のJSのエコシステム(gulpとかそういうの)を使うにあたってこのようにしたというメモ - Qiita

    ちょっと前に触ったサービスでRailsサービスでgulpとかbrowserifyとかそのあたりのモダンなJSツールを使いたくて、こんな感じにやってみたというメモです。 おおまかにいうと、gulpでビルドしたものを、asset pipelineに通すというだけ。 こんなことを考えていた 最初はsprocketsをいっそのこと外してしまおうかと思ったんだけど、そのサービスはasset_syncというassetをS3にあげるgem使ってたのと、digestまわりとかあって、それらは解決できなくはないけど、めんどくせえからそこはsprocketsに任せてもいいやと思ったので、結局外しませんでした。 また、JSまわりのツールsprocketsと連携してたりするgemがあったりするんですが、JSまわりツールのバージョンアップの早さにgemがついていけてないと感じたので、我慢して古いバージョン使うのが嫌

    Railsで昨今のJSのエコシステム(gulpとかそういうの)を使うにあたってこのようにしたというメモ - Qiita
  • SymbolHound: Search Better. Code Better.

    Web Advanced Search SymbolHound is a search engine that doesn't ignore special characters. This means you can easily search for symbols like &, %, and π. We hope SymbolHound will help programmers find information about their chosen languages and frameworks more easily. Example searches: === javascript      scala =>      lisp #'      ruby $$

  • perlの文字列をバイト数で切り取るヤツ - itochin2の日記(仮)

    APIに渡す文字列は25文字(50byte)でよろしく、 という要件に対応するサブルーチンを実装した時のメモ。 サブルーチンでは以下の3つを考慮する。 ・文字数制限を満たす ・バイト数制限を満たす ・文字列として成立する(単純にバイト数でぶった切ると、文字列がおかしくなる 実装の時に調べてしったこと ・bytesプラグラマは非推奨 http://perldoc.perl.org/bytes.html 雑感 文字列は入り口でデコードして、出口でエンコードなんだから、 encodeしてlengthを取るのはごく普通なことだと思った。 あと、文字数がバイト数より大きいくなることってありえるのかなぁ。 よくて同じな気がする。 そうだったら、文字列の長さチェックは省略してもよいのかもしれぬ。

    perlの文字列をバイト数で切り取るヤツ - itochin2の日記(仮)
  • Perl で utf8 文字列を byte サイズで split する - shag の日記

    utf8 な文字列を特定のバイトサイズで切り分ける処理って Perl でどう書けば一番良いのかを長いこと考えてた(あまり困ってはなかった)んだけど、UTF-8文字列をバイト数でカットした時の末尾の処理 見たら簡単に書けた。 #!/usr/bin/perl use strict; use warnings; use Encode qw( is_utf8 decode _utf8_on ); require bytes; my $utf8 = decode( 'euc-jp', "この日語テキストは euc-jp で書かれていますが utf8 に変換されます" ); my @splited = byte_split( $utf8, 12 ); binmode STDOUT, ':utf8'; printf "utf8 string = %s\n", $utf8; for my $str (@

    Perl で utf8 文字列を byte サイズで split する - shag の日記
  • hirotomo.org

    hirotomo.org

  • 開発スピードをあげるには - パルカワ2

    「開発スピードをあげろ!」と言われる事は多々ある。 実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず!」と人を追加する。しかし、根的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。 開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。 例えば、「仕様決め」の問題点は 仕様が決まらず、MTGの時間が長い 仕様を決める人がいない 誰かに確認する事が多い 開

    開発スピードをあげるには - パルカワ2
  • [Ruby] Ruby 3.0 の特大の非互換について - まめめも

    タイトルは釣りです。すみません。Ruby 3.0 はかなり先の将来の話なので、最終的にどうなるかはわかりません。でも Ruby 3.0 に重大な変更が予定されているのは事実なので、一緒に考えて欲しいと思います。 immutable string literal Ruby 3.0 では文字列リテラルをデフォルトで immutable (破壊的変更不可) にする、という方針が『決定』しました。(Feature #11473: Immutable String literal in Ruby 3) つまり、次のようなプログラムが動かなくなります。(当チケットから少し改変して引用) sql = "SELECT #{sec_id}, pt.path, st.doc_count " sql << "FROM #{stats_tablename} AS st " #### ←ここで例外: can't m

    [Ruby] Ruby 3.0 の特大の非互換について - まめめも
  • マルチモデルデータベースを用いたデータモデリング | POSTD

    同じデータストア内に異なるデータモデルを適合させるためのケーススタディ。 最近になって、”多言語パーシステンス”という考えが新たに登場し、ポピュラーになってきました。参考として、 Martin Fowlerが自身のブログに投稿した素晴らしい記事 をご覧ください。Flowerの基的な考えを解釈すれば、大規模なソフトウェアアーキテクチャにおけるパーシステンス層の異なる部分に対して、適切なデータモデルを色々と使うことは有益である、ということになります。このことから、例えば、永続的に構造化されるリレーショナルデータベースには表形式のデータ、非構造化データ向けのドキュメントストアにはオブジェクトライクなデータ、ハッシュテーブル向けのキー/バリューストアには高度に関連付けられた参照データ向けのグラフデータベースを使うこともできるということです。従来の考え方では、これは同一のプロジェクト内で複数のデー

    マルチモデルデータベースを用いたデータモデリング | POSTD
  • 正しい製品を作る / 製品を正しく作る - ninjinkun's diary

    Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節 エンジニアリング部門というのは、基的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。 というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング(実装)」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。 エンジニアは製品を正しく作る エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。 エンジニア

    正しい製品を作る / 製品を正しく作る - ninjinkun's diary