文系でもプログラマになれるのか - そーだいなるらくがき帳
ブログについたコメントに対する自分なりの考えを書く。 soudai.hatenablog.com 私は文系の大学生ですが、プログラミング興味を持ちプログラマになりたいと考えています。 とても難しい事は理解していますが、プログラマに就職するのは やはり難しいでしょうか？ もし可能性があるとしたら、就職先の探しかたや見分け方などの ことを教えてください？ お願いします。 文系でもプログラマを始めとするソフトウェアエンジニアになれるか？の答えは なれる。 例えば自分の周りでも id:daiksy さんとか @shinpei0213 さんは文系出身のソフトウェアエンジニアだしプログラミングしている。 もっと言えば自分自身、高卒エンジニアなので学歴がネックでプログラマになれないということは無い。 だがソフトウェアサイエンスをしっかりと学んだ人からするとスタートラインは後ろである、という事実はあるし、
AWS をどう使わずにおくか - portal shit!
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
Chaos Engineering やっていく宣言 - クックパッド開発者ブログ
技術部のヨシオリです。 Netflix が Chaos Engineering の論文を公開して 2 年ほど経ちました。 クックパッドは最近、 Chaos Engineering を導入する事を決めました。 この記事ではその背景を紹介したいと思います。 そもそも Chaos Engineering とは Netflix では Failure Injection Testing として、営業時間中に意図的に障害を起す事をやっていました。Chaos Monkey というインスタンスとサービスを落すものから Chaos Gorilla、Kong という availability zone や region 単位で障害を発生させるものなどです。 その経験から Chaos Engineering というものが提唱されました。 Principles of Chaos Engineeringによれば C
巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと - クックパッド開発者ブログ
会員事業部ユーザー基盤チームエンジニアの井口(@iguchi1124)です。 ユーザー基盤チームでは、クックパッドのサービス開発者のあらゆる要望に答え続けられるような『柔軟でいい感じのユーザー基盤』を目指し、サービス開発者およびユーザーさんの課題と向き合いながら日々開発を進めています。 第一弾として、普段の開発の様子や一部のユーザーさんに向けてユーザー登録機能をリリースするまでの話も公開されていますので是非そちらもご覧いただければと思います。 今回は、上述の記事にも触れられているようにクックパッドでユーザーさんのアカウント登録や認証情報として電話番号を利用できるようになりましたので、そのためにやってきたことの一部をご紹介したいと思います。 一口に電話番号を利用出来るようになったと言うと簡単そうに聞こえますが実際にはそうでもありません。 クックパッドではこれまで連絡先情報あるいはアカウントの
Go言語で書いた Web アプリケーションの習作をサービス化して公開するところまでやってみた - えいのうにっき
もともと数ヶ月前から、Go言語によるWebアプリケーション開発 を読みながら Go での Webアプリケーション開発の勉強をしていた。 Go言語によるWebアプリケーション開発 作者: Mat Ryer,鵜飼文敏,牧野聡出版社/メーカー: オライリージャパン発売日: 2016/01/22メディア: 大型本この商品を含むブログ (3件) を見る 「実際に動くもの」を、「手を動かして作りながら学ぶ」のが僕は好きで、今回も同様、それを楽しんでやっていたのだけど、思いの外それっぽいものができあがってしまって。これをそのままローカルで動かすだけじゃおもしろくないな、もったいないな、と思ったので、それをサービス化して公開するところまでやってみた。 かんじんのアプリケーションは↓これ。Yukizuri と書いて「ゆきずり」と読む。 https://yukizuri.moshimo.worksyukizu
ISUCON7で惨敗してきました
タイトルの通りです。一応自分達のメモ用に何をしたのか簡単に残しておきます。 事前準備去年ISUCON6では出題側だったので久しぶりの出場でした。一昨年まで一緒に出ていたチームではなく、今年は鍋部として『@walf443, @st-cyrill』の3人で出ました。 事前に数回練習を行い、お互いのやることなどを決めていきました。自分はアプリケーション担当としてアプリケーションの特徴や実装を調べたり、実際の実装を進める役割でした。 今年は例年と違い、予選からサーバーを運営側が提供だったので運営側の負担を考えたら複数台は絶対にやらないと思っていました。しかし事前に公開されたレギュレーションには複数台という文言がありました。それを見たときに正気か！？と思いました。 正直当日まで複数台については懐疑的でしたが、実際には複数台でした。もう少し複数台で出題されたときの対策を真面目に考えるべきだったな、と後
GAEのカスタムドメイン無料SSL化で静的コンテンツ配信を試してみた - えいのうにっき
Google App EngineでマネージドSSLが全ユーザーに無料提供、HTTPSの導入が簡単に。証明書の更新もGoogleにおまかせで心配無用 － Publickey というニュースを目にしたのが先週の火曜日・9月19日。 www.publickey1.jp 「GAE 、どんどん便利で最高になっていってるなぁ......」と思わず遠い目をした僕は、おそらく古参GAEユーザーと言っても差し支えはなさそう。記録（このブログ）によると、2009年に GAE を触り始めていた。GAE をメインで扱う Web 起業にエンジニアとして働いていたこともある（2012 - 2013）。なので、昔の不便......いや、荒削りな頃の GAE はイヤというほど触り倒していた。 それもあって、今回の報はとても嬉しかったし、ただでさえ「またそろそろ GAE でおもしろいことやりたいなぁ...」と思っていたと
レガシーPHPプロダクトのアプリケーションアーキテクチャ改善活動（第3回/全3回） - Pepabo Tech Portal
こちらは前回の記事からの続きとなっております。 第1回の記事で「上と下から同時に攻める」という方針を掲げ、そのうち下から攻める（既存のロジックの切り出し）の部分の改善をこの記事でご紹介していきます。 下から攻める 1. 外部ライブラリをComposer管理へ移行 JUGEMの既存のコードの問題として、ダウンロードしてきた外部ライブラリ（主にPEAR）があちこちに配置され、どこまでが自分たちのコードでどこまでがそうではないのか分からなくなっている問題がありました。まずは自分たちで管理すべきコードのみが残るように外部ライブラリを整理していきます。 こちらは全ての外部ライブラリを根こそぎ調査してバージョンの特定を行い、Composer管理へ移動できそうなら全て移動していきました。 こちらの内容はYAPC::Asia Hachioji 2016 mid in Shinagawaにて発表した資料があ
Go言語感想文 - なるせにっき
序 最近、敵情視察を兼ねた仕事ととしてGoでアプリケーションを書いていた。このアプリケーションがどんなものかはそのうちid:tagomorisさんがどこかで話すと思うけれど、このコンポーネントがOSS化される予定はいまのところないので、そこで得た知見をここにまとめておくことにする。 GoroutineとChannel さて、GoといえばGoroutineとChannelですね。 Goroutineはようするにスレッドなんですが、文法と実装の支援でより気軽に使えるのが他の言語との違いでしょうか。なので、Goroutineをどれだけほいほい使うべきかというコスト感覚を身につけることがとても大事な気がします。Rubyなどとは気持ちを切り替えていく必要があるでしょう。ぼくはまだ切り替えきれていません。 もう一つがChannelですね。これは端的にはメッセージキューです。 Goは前述の通り同時に動く
Rails を使った EC アプリケーション開発について学べる本 "Take My Money" を読んだ - kymmt
読みました。 Take My Money: Accepting Payments on the Web 作者:Rappin, NoelPragmatic BookshelfAmazon どんな本か 副題が "Accepting Payments on the Web" となっているように、決済 (payment) システムをもつ Web アプリケーションを作る方法について説明しています。『達人プログラマー』などでおなじみの The Pragmatic Bookshelf シリーズの本です。 チケット販売システムの開発を通して、次のような具体的な話題に触れています。基本的には Rails 5 を使ってロジックからビューまでを開発していきます*1。 決済システムの実装 ショッピングカート 外部決済サービスとの連携 サブスクリプション機能 エラーケースとその対策 管理画面の実装 返金など注文の操
YAPC::Kansai 2017 OSAKA にはてなから4人のエンジニアが登壇します - Hatena Developer Blog
こんにちは。はてなアプリケーションエンジニアの id:astj です。 Perl は5も6も好きです。 昨年12月の YAPC::Hokkaido を皮切りにリブートした YAPC::Japan の第2弾として、来る2017年3月4日に YAPC::Kansai 2017 OSAKA が開催されます。 Perlを軸としたITに関わる全ての人のためのカンファレンスであるこちらのカンファレンスに、はてなのエンジニアが4名（前夜祭を含めると5名！）登壇しますので以下にトークを紹介します！ 既にチケットは売り切れてしまっていますが、参加されるみなさまと会場でお会いすることを楽しみにしています。 詳細はカンファレンス公式サイトをご覧下さい。 yapcjapan.org また、カンファレンスの前日である3月3日にはYAPC::Kansai 2017 OSAKA 前夜祭 in大阪も開催されます。こちらも
Vuex の公式ドキュメントを翻訳した - おいちゃんと呼ばれています
Vuex は Vue.js アプリケーションのための状態管理パターンのライブラリ。Flux、Redux そして The Elm Architecture から影響を受けている。 その Vuex の公式ドキュメントの翻訳を2016年11月〜12月に @kitak @tady_jp @kimikimi714 とともにやらせていただいたのでアナウンス。だいぶ書くのが遅くなってしまったけども。 https://vuex.vuejs.org/ja/ Translate v2 docs in Japanese. by kitak ・ Pull Request #428 ・ vuejs/vuex きっかけ Vue.js 本体の 2.0 のドキュメント翻訳が終わろうとしていた頃に、元同僚かつ同じチームで仕事をしていた @kitak が Slack の vuejs-jp で一緒にやろうと呼びかけていたので乗
重要！ まずは「オリジン」を理解しよう
連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。今回から、HTML5やJavaScriptに関連したセキュリティの話題について連載することになりました。よろしくお願いします。 もう読みましたか？ HTML5のWebアプリセキュリティに関する報告書 皆さんすでにご存じかと思いますが、2013年10月30日にJPCERTコーディネーションセンター（以下、JPCERT/CC）から「HTML5 を利用したWebアプリケーションのセキュリティ問題に関する調査報告書」が公開されました。 この報告書の調査の一部は、弊社が行いました。また、JavaScriptのセキュリティ上の問題について次々と鋭い指摘を行っているmalaさんにもさまざまな技術的アドバイスを頂いた上、日常的にWebアプリケーションのセキュリティ検査や構築を実際の業務として行っておられる専門家の方々にも査読をお願いして
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
Android 4.4 詳解 Printing Framework 前編
ちょいAndroid。Typescriptいいよ。JenkinsとかGradleとか。APTもいいなー。 俺がPrinting Frameworkだ！という事で、「Android 4.4 KitKat 冬コミ原稿リレーを開催」の11/9担当のsys1yagiです。 本記事では、Android 4.4で追加されたPrinting Frameworkで出来ることや、アプリケーションでPrinting Frameworkを使う方法などを解説します。内容はPrinting Contentをベースにしています。のちほどPrinting Contentの日本語訳も公開する予定です。 今回の解説に登場するコードはGithubで公開しています。→PrintingFrameworkSample エミュレータとGalaxy Nexusに焼いたAndroid 4.4で動作確認しています。N5マジほしい。 Pri
OWASP Japan、Webアプリの一般的なセキュリティ要件をまとめた文書公開
OWASP Japan、Webアプリの一般的なセキュリティ要件をまとめた文書公開：開発者にも、そして発注者にも安全なWebアプリの要件定義を OWASP Japanは2013年11月1日、Webシステム／Webアプリの開発において一般的に盛り込むべきと考えられるセキュリティ要件をまとめた「Webシステム／Webアプリケーションセキュリティ要件書」を公開した。 OWASP Japanは2013年11月1日、「Webシステム／Webアプリケーションセキュリティ要件書」を公開した。安全なWebアプリケーションを実現するため、開発を依頼する発注者側と、実際に開発を担う受注者側の双方が留意すべき要件についてまとめている。 The Open Web Application Security Project（OWASP）は、Webアプリケーションのセキュリティ改善に向けた啓発、研究活動を行う非営利団体だ
世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全なPHPアプリケーションの作り方2013