フリーエンジニアのIT案件ならレバテックフリーランス
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
『JavaScript: The Good Parts』で紹介されている標準メソッドまとめ - Qiita
『JavaScript: The Good Parts』で紹介されている標準メソッドまとめ JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティスは、JavaScriptの「良いパーツ」のみを厳選した、JavaScriptを書く人なら一度は読んでおきたい 良書です。したがって、ここで紹介されている標準メソッドは、積極的に取り入れるべきメソッドです。 「車輪の再発明はするな」とはよく言われることですが、標準APIに詳しくなることで普段書くJavaScriptもかなりきれいにまとまって書けるようになります。 本記事では省いているRegExpやNumberの節、または標準メソッド以外のJavaScriptの「良いパーツ」に興味が出た方は、一度本書を手にとって見てみてください。 「JavaScriptは言わばひとかたまりの大理石であり、私はその中からこの言語
Composerを速くするために必要だったもの // Speaker Deck
PHPカンファレンス関西2016の基調講演です。
読みやすいREADMEを書く | Yakst
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
全てのRubyエンジニアはだいたい糞である
汎用系のエンジニアからRubyのエンジニアとして転職して1年。 コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。 その特徴はだいたいこの3つだ。 1.テストを甘く見ているやれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。 そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。 テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。 そもそもテストケース表を若いうちに書く習慣が無いからだ。 ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。 2.パフォーマンスを考えないRubyエンジニアはパフォーマンスを考えない。 どのメソッドがどれくらいの負荷なのか意識
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
プログラミングの名言をもう少し | POSTD
前回投稿した「 The Wisdom of Programming （プログラミングに関する名言の知恵）」で、表面上は良さそうでも、ソフトウェアの開発において誤った考えを助長する結果になってしまう名言に注意を促しました。また、以前には「 favorite programming quotes 」（お気に入りのプログラミングの名言）というのも投稿していますが、もう少し名言を追加しておきたいと思います。 コーディング作業 「プログラムを詳細にわたって明確に記述する作業とプログラミングの作業は、全く同一のものである」―Kevlin Henney 「プログラム構築の本質のほとんどは、実際には仕様書のデバッグだ」―Fred Brooks 「よくある誤った考えは、プログラムの作成者は不可解なコードを書いてもコメント行で自分の考えを明確に表現できるだろうと思い込むことである」―Kevlin Henney
【プログラミング】退職した先輩が書き残していったコメントがひどすぎる・・・ - 意識低い系ドットコム
こんにちは、意識低い系サラリーマンのKENです。 今回は零細IT企業でシステムエンジニアをしている僕が遭遇した酷いコメントについて。 猫でもわかるC#プログラミング 第3版 (猫でもわかるプログラミング) 作者: 粂井康孝 出版社/メーカー: SBクリエイティブ 発売日: 2016/02/27 メディア: 単行本 この商品を含むブログ (2件) を見る 通常プログラムを組むときは、プログラミング言語を使ってソースコードを書いていきます。でもプログラミング言語だけでひたすら書いていると、第三者が読んだときや後から自分で見返したときにわかりづらいので、「コメント」と呼ばれるメモ書きを付記することがあります。あります、というかほとんどの人はそうします。 例えば、「C#」というプログラミング言語だと、行の先頭に「//」と打つと、その行はプログラムの一部としては解釈されず、単なるメモ書きとコンピュー
プログラマ向けノートアプリQuiverが素晴らしい(Mac用アプリ) – namaraii.com
プログラマ向けノートアプリQuiverが素晴らしい(Mac用アプリ)Markdownをサポートしたメモアプリは数多くありますが、技術系のメモやスニペットを書き溜めるのに適したものはそれほど多くありません。 個人的な要件としては、 データフォーマットがオープンで好みのクラウドサービスで同期できることMarkdown(GFM)を扱えてプレビューできることコードの取り扱いが簡単なこと(できればシンタクスハイライトも)ファイルを意識しないで使えること(ファイル名を考えたりしなくて良い。オートセーブされる)ノートブック、タグなどでノートを整理・分類できることぐらいなのですが、すべてを満たしたアプリをなかなか見つけられず、Day OneやUlysses、Kobitoなどを併用して凌いでいましたが、最近、知ったQuiverというアプリがこれらの要件をすべて満たしており、これに一本化することに。 あまりに
人は1ヶ月でエンジニアになれるのか
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
grepをよく使うプログラマはどう考えても乗り換えるべき新しいgrepコマンド「ack」:phpspot開発日誌
Beyond grep: ack 2.04, a source code search tool for programmers grepをよく使うプログラマはどう考えても乗り換えるべき新しいgrepコマンド「ack」。 サーバに入ってコードを書いている人はかならず使うgrepですが、grepよりも高速に検索でき、git,svn等のソースコード以外のソースはgrepしないで検索できるツールらしいです。 Perlで書かれていて、Perlの強力な正規表現が使え、ハイライトしてくれます。ソースツリーの下で「ack 検索ワード」で検索するだけというシンプルさもいいです WEBサービスを書いているとhtmlやphp等色々なソースをいじりますが、ファイルの検索対象も選べるため、便利です。 ack --php <検索ワード> でphpのソースのみを対象とし、ack --nophp <検索ワード>でphp
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
iPad miniで持ち歩けるコーディング環境を作る
iPad mini + Cellularを朝一番から並んで買いました！軽くてLTEでネットが使えるということで、外に持ち歩き端末としてはApple史上最高な端末です。 しかし、私は出かけるときには常にコードを書ける環境を持って歩きたいので、結局MacbookProかAirを持って出かけることになってしまいます。 最近、MBP15に代えたのでちょっと持ち歩きが厳しいなと思っていたので、この際iPad miniでコードを書く環境を構築することにしました。 まずはキーボード。前に買ってあったrapoo E-6300をBluetoothで接続してみます。一発でつながったし、サイズ感も良い感じです。 蓋になる形のキーボードも出ているようですが、とりあえずE-6300で問題なさげ。 次にメインとなるエディタです。iPadでソースコードを書くのに適していて、Dropboxに対応しているエディタといえば、
やはりお前らのMVCは間違っている
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編）
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
コーディング規約をまとめてみた (Ruby編) - bojovs::blog
色々なところで見かけるコーディング規約を見て意識はしているのですが、 その時の気分で書き方を変えてしまうことが多々あったので、自戒を込めてコーディング規約をまとめてみました。 「なぜこの規約が存在するか」を明確にするために、できる限り理由も併記しています。 ただかなり主観的な部分があるので、あまり意味がないかもしれません…。 「この記事のこの規約は気に入らない。」と思うことがきっとあると思います。 その時はコメント欄などに理由も合わせて書いてくれると嬉しいです。 この記事ではRubyのコーディング規約をまとめています。 近いうちにRailsとCoffeeScriptのコーディング規約もまとめるつもりです。 Rubyのコーディング規約は以下のページを参考にまとめました。 https://github.com/styleguide/ruby https://github.com/bbatsov
モバイルゲームの歴史を年代別にご紹介します。モバイルゲームの成長と今後について詳しく解説していきます。
モバイルゲーム 物凄い勢いで勃興したモバイルゲーム業界は、いろいろな課題や問題に直面しながらも巨大化し、今日の時点でのスマートフォン向けゲームの市場へと継承されていきます。 モバイルゲームの歴史 2001 Javaアプリと3Dゲームの登場 Javaが利用できるようになったことにより、ダウンロード型のゲームが供給できるようになりました。 2002 携帯電話端末の大容量化・3D化競争 Java搭載携帯電話端末が登場してからごく僅か1年の間に、アプリのサイズに関しては10倍に広大化し、表現方法も2Dから3Dにシフトし始めました。J-PHONEは『ゼビウス』や『スペースハリアー』などといった昔のアーケードゲームを、ドコモはSIMCITYなどパソコンで世界的規模のヒットを飛ばしたゲームを主力商品としていました。 2003 モバイルゲームの一般化 メモリの制限が厳しいJava仮想マシン上ではなく、OS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2016/05/17/20160510please-dont-learn-to-code/
