CodeIQ中の人、millionsmileです。 PHPメンターズの後藤秀宣さん出題の『オブジェクト指向的FizzBuzz』問題の解説記事です! PHPは、開発言語別の求人数ランキングで2位であります(出典)。さらには、PHPが書けてオブジェクト指向がわかるエンジニアへの企業ニーズは高いものの、実際は、まだまだ層が薄いということもあり、今回の出題へ、となりました。 ぜひ解説記事を読んで、イケてるオブジェクト指向がわかるPHPエンジニアをめざしてみてはどうでしょう。 以下、問題文です。 FizzBuzz問題を解くアプリケーションを実装しているとします。 ★FizzBuzz問題とは? 1, 2, 3, ・・・という入力に対して3で割り切れる場合は「fizz」、5で割り切れる場合は「buzz」 3でも5でも割り切れる場合は「fizzbuzz」、それ以外は数値をそのまま出力する PHPコードは次
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
昔Qiitaで書いた内容なんですが、PHPのswitch文は悪名高い「==」演算子で比較を行います。 <?php switch (true) { case 0: echo '数字の0'; break; case '0': echo '文字列の0'; break; case '0.0': echo '文字列の0.0'; break; case true: echo '真偽値のtrue'; break; } このコードは「文字列の0.0」を出力します。大変分かりにくいですね。 この点はif ... elseif ...を使えば解決するんですが、switchで書きたくなるようなコードをelseifにするとおそらく読みにくくなるでしょう。 ではどうするか。 正解はオブジェクトのポリモーフィズム(多態性)機能を使うことです。 といっても、多態性で調べて出てくる記事とか書籍に関しては抽象的な説明が多い
ようこそ 時代遅れの情報がウェブ上にあふれている。そんな情報を見たPHP初心者は戸惑ってしまうだろう。そして、まずい手法やまずいコードが広まってしまう。 そんなのはもうやめよう。PHP: The Right Way は気軽に読めるクイックリファレンスだ。PHPの一般的なコーディング規約、 ウェブ上のよくできたチュートリアルへのリンク、そして現時点でのベストプラクティスだと執筆者が考えていることをまとめた。 大事なのは、 PHPを使うための正式なお作法など存在しない ってこと。 このサイトの狙いは、はじめて PHP を使うことになった開発者に、いろんなトピックを紹介すること。 経験豊富なプロの人にとっても、これまで深く考えることなく使ってきた内容について、新鮮な見方を伝えられるだろう。 このサイトは、決して「どのツールを使えばいいのか」を教えるものじゃない。 いくつかの選択肢を示して、それぞ
fooo↑↑ 動機 僕はただの数学/統計系の学部生で、RやMathematicaなどの言語を強いられる事が多いのですが、 RubyやHaskellやScalaなどのステキな言語を知っていると「ちょっとな〜」と思っておりましたところ、 突然「あ、新しい言語作らなアカン」という不可思議な衝動に駆られ ガッと取り憑かれたように実装し、少し冷静になってQiitaを書いているのが今です. フィードバックを頂きながら育てて行きたいと思います(コミッター絶賛募集中、ワイワイ楽しくやりたいです. アメちゃん差し上げるのでお願いします. ) 現在はコンパイラと4秒くらいで作ったインタプリタがあります. ポリシー 一番大きな観念としては 「紙とペンの感動をキーボードで」 です. 後々の可読性や保守性などはどうでもよくて、 「その瞬間(コードを書いている瞬間)の気持ちよさ、心地よさ、そしてその返値を楽しむ事」
7月19日に行った「覚醒!JavaScript」勉強会で使用したスライドです。 http://connpass.com/event/7082/Read less
例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか? 家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか? そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード 1 不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一
What ORMs have taught me: just learn SQL I’ve come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it. Some background: For the past 30 months I’ve been working with code that has to interface with Postgres and to some extent, SQLite. Most of that has been with SQLAlchemy (
Welcome There’s a lot of outdated information on the Web that leads new PHP users astray, propagating bad practices and insecure code. PHP: The Right Way is an easy-to-read, quick reference for PHP popular coding standards, links to authoritative tutorials around the Web, and what the contributors consider to be best practices at present. There is no canonical way to use PHP. This website aims to
Written by Nate Cook & Mattt July 11th, 2018 (revised) This article has been translated into: 中文 Code structure and organization is a matter of pride for developers. Clear and consistent code signifies clear and consistent thought. Even though the compiler lacks a discerning palate when it comes to naming, whitespace, or documentation, it makes all the difference for human collaborators. This week
先日たまたま、MITメディアラボ所長の伊藤穰一さんのTEDを観たんですが、そこでこういう図が出てたんですよね。 インターネット以前【MBAホルダーがビジネスモデルを描く】→【資金調達】→【作る人を雇う】 解説すると、インターネット以前の時代は、まずMBAをとって、ビジネスについて理解して、ビジネスプランを提示してお金を集めて、それからエンジニアやデザイナなど、作る人を集めたと。 サーバ代とか開発コストだけで数千万から億単位かかってしまうから、お金を引っ張ってくるにはそれなりのビジネスプランが必用になるんですね。 MBAが力の時代です。 インターネット以降それが今どう変わっているのか。 【ともかく作る】→【資金調達】→【MBAホルダーを雇ってビジネスモデルを作る】 パワポも何もわからなかったけど、とにかく「モノを作った」と。するとそこにお金がついて、最終的にお金を稼ぐためにMBAホルダーを雇
先日Rubyビジネス推進評議会主催の第3回Rubyビジネスフォーラムが大阪で開催されました。 Ruby言語開発者、まつもとゆきひろさんが、『インターネットが変えるソフトウェアとビジネス。Rubyを例として』と題した基調講演を行いまいした。 その内容を紹介します。 計算機としてのコンピューター IBMの初代社長トーマス・ジョン・ワトソンの有名な言葉に、「コンピューターは全世界で5台くらいしか売れないと思う」と言ったとされています。 その数字は当時の計算技師の人数とENIACの計算性能から導かれた数でした。 ところが、今ではその数百万倍の処理能力をもつコンピューターが何億台もあります。 去年だけでPC出荷台数は3億台。スマートフォンとタブレットはそれを超える出荷がされています。 コンピューターは計算機としてのみ使われているわけではありません。 インターネットとの接続 今日、大阪まで松江から飛行
こんにちは。開発担当の渡部です。 普段の業務では Web のフロントエンド・サーバーサイドをやりつつ、オフの時は Oculus Rift を触っており Developers Summit 2014 などのイベント等にも多数参加していますが、 本日はジワジワと伸びているプログラミング言語についてのお話です。 つい先月、このブログでも取り上げた Objective-C 後継として開発中の Apple Swift や、 JavaScript を置き換えるものとして作られている Google の Dart や Microsoft の TypeScript などのように、既存の言語に限界を感じて新しい言語を作るというケースは非常に多いです。 今回はその中から、ハードウェアレベルからアプリケーションまで扱えるシステムプログラミング言語として不動の地位を築いているC言語の後継という大きな目標を掲げて開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く