タグ

ブックマーク / gihyo.jp (96)

  • 第22回 Mojolicious::Lite:本当に簡単なウェブアプリがあればいいときは |gihyo.jp … 技術評論社

    あれから1年 Mojoについては2009年1月1日から4回にわたって特集記事を連載しました。ちょうど執筆を開始した直後に作者リーデル氏が不幸な医療事故にあい、一時はどうなることかと思いましたが、連載を終了する直前に開発続行の宣言が出て、ほっとしたのをよく覚えています。 あれから1年。Mojoを取り巻く環境はずいぶん変わりましたが、いま、Mojoはいったいどうなっているのでしょうか。今回は今年最後の記事として、Mojo界隈の近況をお届けすることにします。 大きく変わったといわれていますが…… 昨年12月にバージョン0.9に到達したMojoは、途中事故の後遺症で開発が停滞した時期はあったものの、この1年でかれこれ30回以上のリリースが行われたことからもわかるように、いまもなお着実に開発が続けられています。この「ベータテスト」期間中にいくつか後方互換性が失われる変更があったため批判を浴びたことも

    第22回 Mojolicious::Lite:本当に簡単なウェブアプリがあればいいときは |gihyo.jp … 技術評論社
  • Perl Hackers Hub:連載|gihyo.jp … 技術評論社

    最終回 Carmelによる依存モジュール管理 CPANモジュールの更新を高速⁠⁠、安全に(2) 宮川達彦[著],牧大輔,福貴之,松木雅幸,大沢和宏[監修] 2023-10-17 最終回 Carmelによる依存モジュール管理 CPANモジュールの更新を高速⁠⁠、安全に(1) 宮川達彦[著],牧大輔,福貴之,松木雅幸,大沢和宏[監修] 2023-10-16 第79回最近Perlに追加された実験的機能 try文⁠⁠、defer文⁠⁠、class文(2) 石垣憲一[著],牧大輔,福貴之,松木雅幸,大沢和宏[監修] 2023-08-18

    Perl Hackers Hub:連載|gihyo.jp … 技術評論社
  • 2013年関心のある技術は?トップ10発表、テック界のスター誕生!「CROSS VS」、アンカンファレンスも大賑わい ~「エンジニアサポート新年会2013 CROSS」レポート(後編) | gihyo.jp

    個別技術では、MySQLのI/O負荷を軽減するようなテクノロジーが発達していることから、エンジニアの質というよりは、単にコストの問題として捉えて現状の課題解決を図るようなものが多かったようです。 伊勢さんからは、変化していく技術のなかでひたすらにトレンドを追いかけて行くのではなく、エンジニア自身が好きな技術をひたすら追いかける、現状の課題解決のためだけにテクノロジーを採用するのではなく、エンジニア技術を高めるほうが、モチベーション的にも、企業の成功のためにも重要だというお話があり、テクノロジーとの関わり方について非常に考えさせられました。 以上、だいぶ端折ってしまいましたが、それぞれの技術項目での非常に深い話、エンジニアの生き方についての話、の売れ行きの話ありと、多彩な内容となりました。来年は、「⁠アニメでわかる◯◯」シリーズのランキング企画でお会いできればと思います。 「CROSS

    2013年関心のある技術は?トップ10発表、テック界のスター誕生!「CROSS VS」、アンカンファレンスも大賑わい ~「エンジニアサポート新年会2013 CROSS」レポート(後編) | gihyo.jp
  • 第8回 宝くじでひと山当てるプログラムをPythonで作るには?─辻真吾からの問題 | gihyo.jp

    問題 購入者が数字を選択できる、架空の宝くじがあったとします。この宝くじLOTO-Gは、1から40までの数字の中から、5つの数字を選んで、一口500円で購入します。 一度の開催で20万~30万口売れているようです。集まったお金の40%は主催者の取り分です。残りの60%が当籤金として支払われます。これを「当籤準備金」と呼ぶことにします。 抽選によって、5つの数字からなる当たりが1つ決められます。当籤の基準は、1等から3等まで、以下のとおりです。 選んだ5つの数字がすべて当たりと一致した場合⇒ 1等 4つの数字が一致した場合⇒ 2等 3つの数字が一致した場合⇒ 3等 当籤準備金は、以下のルールで山分けされます。 1等⇒ 当籤準備金の半分 2等⇒ 当籤準備金の1/3 3等⇒ 当籤準備金の1/6 それぞれ該当者がいない場合は、当籤準備金は次回以降の開催へ繰り越されることにします。ただし、このことは

    第8回 宝くじでひと山当てるプログラムをPythonで作るには?─辻真吾からの問題 | gihyo.jp
  • 第4回 Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介 | gihyo.jp

    Happy Testing Perl 第4回Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介 モバイルファクトリーの小林です。今回は今までに紹介しきれなかったPerlのTestingモジュールで良く利用されるものをいくつか紹介したいと思います。 Test::Perl::Critic このモジュールはテスト対象のコードがPBPに準拠しているかどうかをテストしてくれるモジュールです。 PBPとはDamian Conway氏の提唱するPerl Best PracticesというPerlのコードを書く際のスタイルです。 http://www.oreilly.co.jp/books/4873113008/ Perl Best Practicesについての詳細

    第4回 Test::Perl::Critic, Test::Pod, Test::Pod::Coverage, Test::Exception, Test::Warn, Devel::Coverの紹介 | gihyo.jp
    mfham
    mfham 2013/01/15
  • 2013年のソーシャルWeb | gihyo.jp

    この傾向だけを見れば、今年は「すでに飽和状態に近い市場に対して、一定数のユーザのシェアを奪い合う」という構図になるということが言えるのですが、事情はそこまで単純ではありません。「⁠当に飽和しているのか?」ということをもっと考える必要があります。 無料通話アプリが開く新たなゲーム市場 筆者が「飽和していないのでは?」と懐疑的になる根拠は、昨年に大ヒットした無料通話・トーク機能を持つスマートフォンアプリの存在です。LINE、comm、そしてカカオトークといったアプリが多くのユーザに使われ出した年が昨年だったと言えます。これらのアプリを使っているユーザは、おそらくGREEやMobageといったソーシャルゲームのアクティブユーザとは被っていないと考えられます。どちらかというと、mixiやTwitterを使ってきたユーザと言えます。 例えば、すでにLINE POPは多くのユーザが遊んでいます。この

    2013年のソーシャルWeb | gihyo.jp
  • 第2回 勉強会の種類 | gihyo.jp

    現在執筆中の(技評SE選書)では、勉強会についての情報もいろいろ盛り込んでいます。IT業界で自分のスキルアップのために勉強をするには、できる人が集まっている「勉強会」という場を生かさない手はありません。もちろん、勉強会で話しを聞くだけでは真の実力は身につかないので、自分でも努力し、勉強会の場でも伸ばし…というスパイラルを描くことが大切です。 さて、勉強したい分野を見つけ、自分でちょこちょこ勉強していて、「⁠最新の話とか、深い話を聞きたいなぁ」「⁠ちょっと分からない所があるから教えてほしい」「⁠同じモノ・コトを勉強している仲間が欲しい」と思ったとします。そうなると次にやることは、自分が学びたいことを扱っている勉強会を探して、というステップになります(人によっては自分でできる人を集めて開催しちゃう人もいます)が、実は勉強会にはさまざまな種類があります。勉強会の参加募集サイトを見るとおおよそど

    第2回 勉強会の種類 | gihyo.jp
  • 第74回 形態素解析とライフログシステム | gihyo.jp

    語を単語に分ける形態素解析 筆者が運用しているライフログシステムのうち、いくつかのモジュールには、文章から単語を取得するための日語の形態素解析システムを組み込んでいます。 形態素解析は、英語のように単語を分けて表記しない日語の文章を、単語に分割する処理をいいます。 たとえばニュースからトレンドを取得してリマインドするような場合には、形態素解析による単語の分析があるとよいのです。 ライフログシステム全体では日々、約100~200ファイル程度を形態素解析しています。この程度の規模で実用に使うために、奈良先端科学技術大学の開発した『茶筌』を使用しています。 奈良先端科学技術大学の開発した『茶筌』 現在は、sourceforgeで入手できます。 ほかにもいくつか形態素解析システムはあるのですが、Windows用でインストール用のドキュメントがわかりやすいものというと、『⁠茶筌』が筆頭でした

    第74回 形態素解析とライフログシステム | gihyo.jp
  • 第16回 Perl内部構造の深遠に迫る(1) | gihyo.jp

    連載では第一線のPerlハッカーが回替わりで執筆していきます。今回はgfxこと藤吾郎さんで、テーマはPerlの内部構造です。 内部構造を覗く Perlで開発をしていると、ときどきわかりにくい現象に遭遇することがあります。たとえば、あるデータをJSON(JavaScript Object Notation)にシリアライズするとき、数値としてシリアライズしてほしい値が文字列としてシリアライズされてしまう。あるいは、エンコーディングが正しいはずなのに文字化けが起きる。こんなときは、思いきってPerlの内部構造を覗くことで、何が起きているかを突き止めることができます。 稿では、Perlの内部構造について解説します。言及するperlはバージョン5.16.0(2012年5月21日リリース)です。また、ターミナルのエンコーディングはUTF-8を想定しています。なお、Perl処理系はC言語で書かれてい

    第16回 Perl内部構造の深遠に迫る(1) | gihyo.jp
    mfham
    mfham 2012/12/20
  • 第1回 大規模データではRDBMSのどこがボトルネックになるのか? | gihyo.jp

    RDBMSはオワコン? 「右を向いても左を向いても“⁠ビッグデータ⁠”というキーワードが闊歩する時代に、いまさらRDBMSの話題?」 連載のタイトルを見てそう思われたかもしれません。 「ディスクベースのRDBMSはオワコン、これからは○○(お好きなアーキテクチャを入れてください)の時代だ!」 とおっしゃる方もいるかと思います。 しかし、むしろ多くの企業がビッグデータに注目しているおかげで、RDBMS側でも大規模データを取り扱うニーズが増えています。 大規模データを取り扱う時にボトルネックとなる5つのポイント 数百ギガバイトといったレベルのRDBMSであれば、現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし、テラバイトを大きく超えたデータを扱う場合には、ボトルネックの傾向が変化するのはご存じでしょうか。 次の図は、RDBMSにまつわるボトルネックを示したものです。 図1 大規

    第1回 大規模データではRDBMSのどこがボトルネックになるのか? | gihyo.jp
  • 第1回 未来のサービスをどうデザインするか | gihyo.jp

    未来のサービスをデザインする「ATL」 ATL(Advanced Technology Lab.)は、多くのサービスを持つリクルート(図1)の中で、新しい技術の開拓や次のトレンドをいち早く察知し、未来のサービスにいかせるソリューションを生み出す部署です。 図1 リクルートのサービス領域 ATL発足のきっかけ 従来リクルートのWebサービスでは、とくにミドルウェアなどにおいて商用製品を中心に活用してきていました。たとえば某商用の検索エンジンを利用していた時期、維持コストに見合うような満足な結果はなかなか出せないでいました。そこで、以前から基礎技術のリサーチを進めていたオープンソースの検索システムであるSolrを導入してみたところ、大きなコストメリットを出すことができました。今ではリクルートの検索エンジンは、そのほとんどがSolrを利用したものとなっています。 また、「⁠ビックデータ」の代名詞

    第1回 未来のサービスをどうデザインするか | gihyo.jp
  • 第16回 ブランドサイトの目的と役割 | gihyo.jp

    ブランドサイトには未だ明確な目的を持たないものが数多く存在します。広告の延長として詳細な製品情報を伝え、デザインやコンテンツを通じてブランドイメージを表現するだけでは具体的なブランドの課題に応えることはできず、明確な存在意義を示すことはできません。 ブランドサイトの目的はブランドからの購入に至るまでにユーザーが体験すべき行動(以降、ブランドアクション)を効率的に実現することです。しかし、ブランドにはそれぞれ個別のマーケティング課題が存在し、優先すべきブランドアクションも異なるため、すべてのブランドに当てはまる成功法は存在しません。ブランドサイトはブランドが抱える個別の課題の解決に向けて綿密に設計されるべきであり、ブランドの課題が明確でなければ役割を持つことはできません。 達成すべきブランドアクション ブランド担当者がブランドサイトのKPIに悩む理由はここにあります。多くのブランドサイトは設

    第16回 ブランドサイトの目的と役割 | gihyo.jp
  • Webサービスつくってるけど何か質問ある?―「ボケて」のゆーすけべーと「nanapi」のけんすうが答えました!(前編) | gihyo.jp

    Webサービスつくってるけど何か質問ある?―「ボケて」のゆーすけべーと「nanapi」のけんすうが答えました!(前編) 秋葉原の書泉ブックタワー9Fのイベントスペースにて、11月30日(金)19時より和田裕介さん著『Webサービスのつくり方 ――「新しい」を生み出すための33のエッセイ』出版記念イベント「Webサービスつくってるけど何か質問ある?」が開催されました。この記事ではその内容についてレポートします。開始時刻になっても和田さんが現れないハプニングはありましたが、イベント開始の数分後に和田さんも会場に姿を現し、その後はつつがなく進行していきました。 知り合ったきっかけは1981年生まれの会 イベントには、『⁠Webサービスのつくり方 ――「新しい」を生み出すための33のエッセイ 』著者であり「君のラジオ」や「ボケて」の開発者としても知られるエンジニアの「ゆーすけべー」こと和田裕介さん

    Webサービスつくってるけど何か質問ある?―「ボケて」のゆーすけべーと「nanapi」のけんすうが答えました!(前編) | gihyo.jp
  • 第16回 生産性を上げるソースコードの書き方 | gihyo.jp

    ソフトウェア開発の難しさ ソフトウェアの開発プロジェクトに少しでも関わった人は誰でも知っていると思うが、ソフトウェア作りで最も難しいのは「スケジュール通りにソフトウェアを完成させること」である。 バグがなかなか修正できず泥沼にはまってしまったり、変更され続ける仕様のために当初立てたスケジュール表がまったく役に立たなくなってしまったり、スパゲッティコードに頭を抱えたりということはよくある。出口の見えない状況でソフトウェアエンジニアが過酷な労働を強いられる状況を「デスマーチ」(⁠death march)と呼ぶが、そんな言葉が存在すること自体が、ソフトウェア作りの難しさを表している。 ソフトウェアの開発は「生産活動」ではあるのだが、建物を建てる、料理を作る、野菜を育てる、ハードウェアを組み立てるなどの生産活動とは大きく違うのだ。 建物の場合で言えば、明確に定義された「設計図」がある。そして、その

    第16回 生産性を上げるソースコードの書き方 | gihyo.jp
  • 第1回 使ってみようMongoDB | gihyo.jp

    第1回目となる今回は、まずMongoDBの概要と特徴的な機能を解説し、どのようなケースで有効に使えるかを紹介します。 NoSQLへの流れ 過去20年間でCPUの処理能力は数十倍になり、ディスクの1バイトあたりの金額は1000分の1になりました。開発環境はクラウドに移行し、扱うデータ量とWebサイトのアクセス数は大幅に増加しました。このような環境の変化から、データストアへ求められるものが変化してきています。 RDBでは、高トラフィックなWebシステムのバックエンドという箇所では、性能の限界があると考えられるようになってきました。その結果、RDBでは性能に限界がある適用箇所にNoSQLを補完することによって補おう、という流れが出てきたと考えています。 図1 データストアに求められるもの NoSQLの分類 現在NoSQLと呼ばれているものは、大きく分けて3つに分類されます。 図2 NoSQLの分

    第1回 使ってみようMongoDB | gihyo.jp
  • 本日12月1日より、プログラマ有志による2012年の技術系Advent Calendarが各所ではじまる | gihyo.jp

    日12月1日より、プログラマ有志による2012年の技術系Advent Calendarが各所ではじまる 日12月1日より、プログラマ有志による2012年の各技術系Advent Calendarが一日目を担当する人のblogではじまっている。定番化したと言っていいほどの、師走の風物詩になっている。 昨年は技術系Advent Calendarが多方面で行われたが、今年は昨年を超える技術系Advent Calendarが12月1日より行われそうだ。 一般的なAdvent Calendarは、12月25日のクリスマスを楽しみに待つために、12月1日から24日までのカレンダーの日付の部分(扉だったりする)を開けるようになっており、1日ずつその日の日付の部分を開くと天使や動物の絵などが見えるという仕組み(もちろん、様々なバリエーションがある⁠)⁠。 これに発想をえて、技術系Advent Calen

    本日12月1日より、プログラマ有志による2012年の技術系Advent Calendarが各所ではじまる | gihyo.jp
  • Gitを使ってみよう:新刊ピックアップ

    Gitが注目される理由 バージョン管理システムとは,ソフトウェア開発をはじめ,各種設定ファイルや論文・原稿(テキスト原稿)など,修正,改訂が発生するファイルを管理するためのしくみです。とくにソフトウェア開発の場合,複数人の開発で利用されることが多く,古くはCVS(Concurrent Versions System⁠)⁠,そしてSubversionというバージョン管理システムが,もっとも一般的なシステムとして利用されてきました。そんな中,Subversionにとって代わる位置づけとして現在,利用者が増えているのがGitです。Googleトレンドで傾向を見るとわかるように(図⁠)⁠,2008年を境にしてGitがSubversionを上回る人気ツールになっています。ここでは,Gitがどうして注目されているのか,ご紹介していくことにします。 開発形態の変化と多様化 従来からよく使われているSub

    Gitを使ってみよう:新刊ピックアップ
    mfham
    mfham 2012/09/11
  • プログラミング生放送勉強会 第17回@品川 レポート | gihyo.jp

    プログラミング生放送勉強会 第17回@品川 2012年8月25日(土)に株式会社マイクロソフトのセミナールームで、コミュニティ「プログラミング生放送(プロ生⁠)⁠」によるIT・開発系イベント、プログラミング生放送勉強会を開催しました。その模様をお届けします。 プロ生勉強会は、IT・開発系であればなんでもOKの勉強会です。今回も、C++11、EPUB3、Kinect、JavaScriptでLINQ、Androidアプリ開発など、ごちゃまぜな構成となりました。すべてのセッションは動画で公開しています。いずれも楽しい内容になっていますので、スライド資料とあわせて、ぜひご視聴ください! 会場の模様。今回は90名の参加がありました プロ生グッズとIT勉強会スタンプラリーの台紙 パッと見でわかるC++11 それでは、各セッション内容を簡単に紹介します。επιστημηさん(@epitwit)からは、C

    プログラミング生放送勉強会 第17回@品川 レポート | gihyo.jp
  • 良いコードってなに?:新刊ピックアップ

    みなさんはどんなコードが「良いコード」だと思いますか? 一般的に,次の4つを満たすものが良いコードです。 保守性が高い 私たちが書いたコードは,私たちが想像するよりも長く利用されます。あとから見て何をやっているのか理解不能なコードは,良いコードとは言えません。将来の自分は記憶力において他人と同然です。つまり,他人が見て理解できるコードであれば,将来の自分が見ても理解できる良いコードです。 すばやく効率的に動作する 良いコードは適切なパフォーマンスで動作します。コードの計算量を常に意識し,最適なアルゴリズムを選択することで,パフォーマンスを高めることができます。 正確に動作する 確実に動作し,信頼性が高いことは良いコードの条件です。「⁠防御的プログラミング」という言葉がありますが,これは「正常な値が来るはず」という決めつけをせずに,不正な値が来ても被害を受けないように防御的にプログラミングを

    良いコードってなに?:新刊ピックアップ
  • 大規模Webサービスの構築・運用の裏側:新刊ピックアップ

    急成長するソーシャルゲーム市場 大規模Webサービスの先駆けとして,ソーシャルネットワークサービス(SNS)が騒がれ始めたのが2000年初頭。日でも2000年中頃に『mixi』『⁠はてな』といった今では当たり前になったサービスが誕生しました。 それから10年,SNSゲームと融合し「ソーシャルゲーム」と進化し新たな発展を遂げています。その代表格の1つが『Mobage』です。 Mobageとソーシャルゲーム 「Mobage」を運営するDeNAは2009年にソーシャルゲームをリリースし2010年からMobageプラットフォームをオープン化しました。2012年現在では,1日に35億PVものアクセス数をさばくWebサービスへと成長し,今後も拡大して行くことでしょう。 日国内で急成長の背景には,以下のような土壌がありモバイル向けゲーム市場が受け入れられたのではないでしょうか? 80年代に誕生した

    大規模Webサービスの構築・運用の裏側:新刊ピックアップ