You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ウェブサービス開発にはエンジニアの存在が必要であり、彼らをまとめて組織の技術力を向上させるCTOは、企業を成長に導くキーとなる存在だ。 ハウツーサイトnanapiを運営するnanapi取締役CTOの和田修一氏は、2005年に楽天に就職、2009年から同社代表取締役の古川健介氏とともにnanapi.jpを立ち上げた人物だ。 同氏がMOVIDA SCHOOLで語った、CTOに必要な役割とエンジニアの組織づくりについてまとめた。 ビジョンとマネジメントが必要な「役員型CTO」 CTOには、大きく2つに分類されると考えている。その1つが役員型CTOだ。私自身がまさにこちらの立場で、役員型CTOはエンジニアリングだけでなく経営全般に対しても責任を持ち、コミットしていかなけばならない。そのため、技術よりも経営を立場上優先しないといけない場合もある。 もちろん、役員といえども技術力は必要だ。ビジョンを持
うーむと悩む 普通に仕事をしていると、うーむと唸っていることが多々あります。主にウェブディレクターとして使うVBAとか、自動化とか、考え方とか。最近はプロジェクトマネジメントだの、中間管理職の悩みだの、が増えてきた気がする。 VBAでPOSTデータを送ること自体はとてもたくさんサンプルがありますが、戻り値の文字コードを変換する部分があまりなかったので作成してみました。 ファイルの入出力が面倒だったので、行なっていません。 Sub sample() Dim mText As String, mParam As String mParam = "hoge=hogehoge&moge=mogemoge" ' 戻り値の文字コードがUTF-8の場合 mText = convTextEncoding(HttpRequest(mUrl, "POST", mParam), "UTF-8") End Sub
VBAからHTTP通信をしたい場合はCreateObject(“MSXML2.XMLHTTP”)でIXMLHTTPRequestオブジェクトを作るのが一番簡単だと思う。XMLHttpRequestはjavascriptでも使用されているので、ノウハウやtipsなどの資料が豊富にある。
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo!デベロッパーネットワークの中野(@Hiraku)です。これまで、JavaScriptで非同期処理を書く上での問題として、コールバック地獄やエラー処理に例外が使えないことなどを解説してきました。 これらの問題に対処するライブラリの1つであるjQuery.Deferredに関して、もう少し丁寧に解説いたします。なお、jQueryのバージョンは記事執筆時点の最新である、1.9.1を想定しています。 jQuery.Deferredとは jQuery.DeferredとはjQueryのバージョン1.5から導入された、非同期処理をうまく扱うための標準モジュールです。使いこなすことで、以下のような効果が見込めます。 非同期処理を連結
2011年05月23日23:12 カテゴリ Python＞継承先のメタクラスは，そのまま書けば良い Pythonで複数のメタクラスを使うときどうしたらいいんだろう？という記事を書いたのだが，それを解決しているコードを教えてもらったので，書いておく． まず元々私が参考にしたのは，Pythonのメタプログラミング (メタクラス) を理解したい人のための短いコード片と禅問答 | TRIVIAL TECHNOLOGIES on CLOUDだった．これを使いメタクラスを2つ書くとこうなる．AはAMetaを持ち，BはAを継承してかつ，BMetaを使う． # coding: utf-8 ''' Created on 2011/05/23 ''' class AMeta(type): def __new__(mcls, name, bases, attrs): cls = super(AMeta, mcl
Ryo Yamasaki(@vierjp)です。 2/13に開催された appengine ja night #23 の前半のセッションで @proppy氏によるDatastoreを中心としたAppEngineのパターンについての説明がされました。 このセッションについて@proppy氏に直接質問させてもらって理解した事も含め、 自身の復習も兼ねて考察してみました。 既に結構時間が立っていますので若干今更感はあるのですが、 書き始めてみると思いのほか濃い内容になった気がします。 なお、後半のセッションでBrian氏によって語られた「Google Compute Engine」については "公開されているドキュメントをベースに、ドキュメントに書かれている範囲で"(重要ｗ) 可能であればajn #23のスライドの内容にも踏み込んで近いうちに記事を書こうかと考えています。 関連リンク： ・app
Experimental API¶ There are a variety of features that are considered experimental in WebOb, these features may change without any notice in future versions of WebOb, or be removed entirely. If you are relying on these features, please pin your version of WebOb and carefully watch for changes. Request¶ The request object is a wrapper around the WSGI environ dictionary. This dictionary contains key
HTTPのステータスコード ▼ HTTP 1.0 2xx：Success (成功) 200OK成功 201Created作成完了 202Accepted受理 204No Content内容が空 3xx：Redirection (転送) 301Moved Permanently恒久的に移転 302Moved Temporarily一時的に移転 304Not Modified変更なし 4xx：Client Error (クライアントエラー) 400Bad Request不正なリクエスト 401Unauthorized未認証 403Forbiddenアクセス権がない 404Not Found存在しない 5xx：Server Error (サーバエラー) 500Internal Server Errorサーバ内部のエラー 501Not Implemented機能が未実装 502Bad Gatewa
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
Stay organized with collections Save and categorize content based on your preferences. App Engine is a fully managed, serverless platform for developing and hosting web applications at scale. You can choose from several popular languages, libraries, and frameworks to develop your apps, and then let App Engine take care of provisioning servers and scaling your app instances based on demand. Learn m
移転しました http://please-sleep.cou929.nu/20130121.html
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
RESTful WebサービスではHTTPステータスコード=処理結果 弊社 アイコン認証Webサービス は、REST方式のWebサービスとして実装されています。 REST方式でない通常のWebアプリケーションでは、通常HTTPステータスコードとしては200(OK)しか返されません。 エラー等の状態を表す場合でもHTTPステータスは200(OK)が返され、画面に表示される内容にエラーを表すメッセージ等を含ませる事によって状態を表現します。 RESTfulなWebサービスを実現する場合には、処理結果はHTTPステータスコードで表現するべきとされています。 理由としては、以下のものがあげられます。 適切なHTTPステータスコードを返さない ( 全部 200 (OK) とかの ) 場合、エンティティの中身を解析しなければ、処理結果が判別できない。 Web標準に従う事で、HTTPステータスコードから
主にプログラミングに関して。Python, .NET Framework(C#), JavaScript, その他いくらか。 記事にあるサンプルやコードは要検証。使用に際しては責任を負いかねます 前回にjQuery.Deferredを使って複数の非同期処理をそれぞれの終了を待って順番に行った。 jQuery.Deferredで非同期処理を書く 配列filesに入れられたファイルを関数showImageで順番に処理するようにとコールバックがごちゃごちゃと回されるように書かれていたところを、わりと素直なfor文で置き換えることができた。 if (files.length) { var str = "showImage(files[0])()"; for (var i = 1, f; f = files[i]; i++) { str += ".then(showImage(f))"; } eva
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
