月別アーカイブ 8月 2019

takahashi 著者:takahashi

PHPは”オワコン”?いやいや…

PHPよりも○○の方がいい、ネット上ではそんな話もちらほら見かけます。

PHPはもう古いから他の言語に乗り換えた方がいい、とかですね。

そんな中、最近こんな記事を見つけました。

PHPはもうダメだ、PHP万歳!- POSTD

“PHPはもうダメだ”といったブログの投稿が、登場し始めたのは2011年のようです(これより古いものを見つけたら、お知らせください)。Mediumや、mushroomsのように突然出現したcoding bootcampsを探し回れば、その唯一の共通点は、みんながPHPを嫌っているか、あるいは単に無視しているかです。どうやら、法外な値段のコーヒーを飲みながら、油まみれのヒゲと皮肉たっぷりのTシャツと一緒に、PHPでコーディングするのは不可能のようです。

ばかな!
もうたくさんです。反PHPのエコーチェンバー現象のせいで、疑わしいビジネス上の決断を下そうとしている創設者に私はいつも話しかけています。
これが現実です。2018年現在、Webサイトの約80パーセントがPHPが使用している
PHPは、なんだかんだ言っても、それほど廃れていないと思います。

https://postd.cc/php-is-dead-viva-le-php/

こちらの記事でも突っ込まれていますが、実際PHPはいまだによく使われている言語であるという話は僕も同感です。

もし使われていなかったら、Laravelのような優秀なフレームワークの開発がどうして継続されるでしょうか。

それに、PHPは本家も定期的にアップデートしている言語ですし、オブジェクト指向もサポートされていますし、いまだにひけをとらない仕様の言語だとも思います。

パッケージマネージャーのComposerもありますしね。

昔からWebサーバーとの親和性もいいので、入門にも是非お勧めしたい言語でもあります。

…とはいえ、自分は必ずしもPHPが100%良いとも考えていなくて、ディープランニングとかにも強そうなPythonとかもちょっと触れるようになりたいなぁ…とかもちょっと考えちゃいますけどね…w

とりあえず、もうしばらくはPHPでプログラミングのノウハウをためてから、是非他の言語もチャレンジしたいですね。







# サーバーサイドもクライアントサイドもなんでもできてしまうJavascriptが実は一番すごいのかもしれない
AI(人工知能)の開発に適したプログラミング言語ランキング8選

  • この記事いいね! (0)
著者:ym

送信メール認証と DMARC

メールが正しいメールかを判断する仕組みとして、最近では SPF や、DKIM は当たり前になってきています。

ただ、DKIM シグネチャの準備もしっかり対応した上で送信してくる迷惑メールもあるので、どちらもいまいちなんですよねぇ。

DMARC というのも、かなり前から目にすることがあったのですが、そういう状態だとなかなかねぇ

最近どこかの記事でDMARCについての話題が出ていたので少し設定してみようかと思います。

  • この記事いいね! (0)
村上 著者:村上

【CSS】テキストの上下中央寄せができない時の対処法

Android 7 以下でのみ発生するテキスト位置のずれに対処したので、その方法についてまとめ。
CSS の height プロパティと line-height プロパティを指定していたのですが、何故か文字が上にずれるという謎現象が発生していました。
そして Android 8 以上の端末や、iPhone では再現せず…。

で、調べたところ下記の記事がヒットしました。

inline-blockで上下が中央に揃えるのに時間かかった – Qiita
https://qiita.com/nagito25/items/fb0e8455a8b2fdcd480b

 

上記の記事によると、子要素に display: inline-block; を指定してある場合、親要素で heightline-height を指定し、子要素で vertical-align: middle; を指定すると綺麗に整うとのことでした。
具体例は下記のとおりです。

<ul>
    <li>要素1</li>
    <li>要素2</li>
    <li>要素3</li>
</ul>

CSS はこちら。

ul {
    height: 50px;
    line-height: 50px;
    padding: 0;
}
li {
    display: inline-block;
    width: calc((100vw / 3) - 6px);
    text-align: center;
    border: solid 1px;
    vertical-align: middle;
}

なお、子要素の li が 1行の場合は vertical-align: middle; を指定しなくてもOKです。
2行以上になる事が考えられる場合は必ず指定しておきましょう。

 

以上、テキストが上下左右中央揃えにならない時の対処法でした。
最初、ずっと子要素の li 内で heightline-height を指定していたのですが、親要素で指定しないと崩れるとは…分かりませんでした。
無事解決できてよかったです。
同じことでお困りの方の参考になれば幸いです。

  • この記事いいね! (0)
asaba 著者:asaba

【php】phpのIDEの充実ぶりがすごい

久々にphpをいじる機会が訪れました。なのでここ最近はもっぱらphpのコードを見たり直接いじったりしています。

自分も学生時代にphpをいじったことがあるのですが、その時は確か秀丸?とかサクラエディタを使っていたのですが

今のphpの開発環境って結構進んでいるんですね。。。

なんせhtmlを開いたり閉じたりしながらエラーを確認していたので、その時の開発の効率の悪さといったら

目も当てられない、悪く言うと黒歴史です()。

 

例えばphpstormはgitとも連携しているしSQL文もきっちり識別してくれます。

javaでいうandroidStudioのポジションですね。家でちょこっと試してみたい・開発したい時もこれを

使って試すなんてことも簡単なので初心者でも他のエディタから移住してきた人でも親しみやすそうですね。

 

JEditはプラグインが充実しているので自分でお好みの機能をつけて自分色のeditに染めてしまう

こともできそうです。

うーん、こいつらいいなと思っていたのですが今僕が使っているatomでも両方できるやんけと思い出したので

シビアなバックエンド開発にならない限りはこのまま変えずに頑張っていきます。

 

 

  • この記事いいね! (0)
著者:杉浦

【PHP】composerを使ったライセンスチェック

 composerはPHPのパッケージインストーラでその中にはいくつか機能があります。機能の一覧はcomposer listで確認できます。composer licensesはその中の機能の一つでcomposerでインストールされているパッケージ全ての名前、バージョン、ライセンス種類を表示してくれます。
 
 ライセンスは深く気にするべき時、しなくていい時があります。どこの誰にでもソースコード込みで公開するOSSの開発時は派生だろうがなんだろうが元のライセンスを継承して完全公開すれば大体OKですが、商用の場合そうもいきません。いくつか避けるべきライセンスがあります。
 避けておいた方が無難なライセンスはGPL系、特にAGPLです。AGPLはAFFERO GENERAL PUBLIC LICENSEの略です。
 GNUアフェロ一般公衆ライセンス – GNUプロジェクト – フリーソフトウェアファウンデーション
 AGPLは次の通りのことをプログラムに要求します。

GNUアフェロ一般公衆ライセンスは通常のGNU GPLバージョン3を改変したバージョンです。これには一つ要求が加わっています。サーバで改変したプログラムを動かし、そこでそのプログラムとほかのユーザに通信させる場合、サーバはユーザにそこで動いている改変バージョンに対応するソースコードのダウンロードも許可しなければいけない、というものです。

 どこまでが改変だとかの解釈は理解していませんが(継承した時点でアウト?)、AGPLのプログラムを含むプログラムを動かした場合、そこに正規でアクセスしたユーザはソースコードも手に入れられなければならない、という状況になりそうです。商用ということは扱うものがものですから悪意のあるユーザへの対策は必須です。ソースコードの公開はセキュリティホールの発見を容易にします。あるいは見つかるはずのなかった穴を見つけさせます(マジックナンバーで書かれた何かしらとか。設定ファイルを介するプログラムを組んでおけばそれだけで回避可能ですが)。
 composerのライセンスチェック機能を使うと、こういった問題を容易に回避できます。やることはシンプルで次のようにcomposer licensesの結果にgrepをかけるだけです。

composer licenses | grep -v -P ^\(?=.*[^,]\(MIT\|BSD-3-Clause\)[^,]\)


 安全安心な許容できるライセンスによるホワイトリストがよいと思います。

  • この記事いいね! (1)
著者:杉浦

モデルでまとめるかモデルを分割するか

 webページを作るとき、多くはモデル、ビュー、コントローラに分けてコーディングを行えます。ざっくばらんには、ビューは与えられた値を適当な形にあてはめるのみのテンプレート、コントローラはモデルに命令を出し値を要求し結果をビューに渡す仲介者、モデルはそれ以外の画面に依らない部分、といった分類です。
 これは実際優秀なのですが、複雑な問題を取り扱うほどモデルが太っていきます。気が付いたら頭の中のハッシュマップが頼りになり出します。単純なCRUDの様なものを扱う程度ならばフレームワークのORM任せで”モデル”と一言で済ませてもあっさり済みますが、そうならない時もあります。そうなる時はモデルを更に分割していく必要があります。モデルの一言でまとめられた要素をhogeモデル、fugaモデルと分解していきます。
 分解の仕方は様々です。様々なので後や他にコードを触る人のために分解の仕方や指針をドキュメントに残すべきです。部分的に何かを用いた場合など、特殊なパターンならばなおさらです。
 分解の仕方は信頼できる先達のモノが良いでしょう。本や説明書などドキュメントされているものが望ましいです。例えば、エリック・エヴァンスのドメイン駆動設計 | Eric Evans, 和智右桂, 牧野祐子, 今関剛 | 工学 | Kindleストア | Amazonです。ドメイン駆動設計ではドメイン(業務知識)に従ってモデルを定義していくやり方を示しています。フレームワークもあると思ったのですが、ORMは用意したから他で自由に書け、といった具合でした。

  • この記事いいね! (1)
村上 著者:村上

【CSS】要素の横スクロールが効かない時の対処法

今日少しハマったので備忘録としてまとめました。
CSS の overflow-x プロパティを使って、要素からはみ出た分を横スクロールで表示しようとしたところ、思った通りに動作せず…。
ただし、スクロールバーだけは表示されていたので、overflow-x: scroll; は効いていたようです。

 

で、原因が分からなかったので検索したところ、下記の記事がヒットしました。

CSSのoverflowを使ってはみ出た表示の指定方法 | TechAcademyマガジン
https://techacademy.jp/magazine/9428

こちらの記事によると、横スクロールを実装する際には、要素に white-space:nowrap; を追加する必要があるとのことでした。
こちらは要素内で自動的に改行しないようにするためのプロパティです。

具体的なコードは下記のとおりです。

div {
    padding : 10px;
    height: 200px;
    overflow-y: hidden;
    overflow-x: scroll;
    white-space: nowrap;
}

上記コードでは、縦スクロールは禁止し、横スクロールを強制にしています。

で、6行目の white-space:nowrap; を追加したところ、問題なく動作しました!
確かに要素内で改行が発生してしまっておりましたが、その解決策が分からなかったんですよね。

 

以上、要素の横スクロールが効かない時の対処法でした。
縦スクロールを実装するときには、単純に overflow-y: scroll; を追加すれば動くことが多かったので、手こずってしまいました。
どなたかの参考になれば幸いです。

  • この記事いいね! (0)
takahashi 著者:takahashi

LPICがややこしいことになっていた件

Linuxまわりの技術力を認定してくれる資格としてLPICというものがあります。

Linux好きとしては是非取っておきたい資格なのですが、このLPICの受験手続周りが最近ごたついているようで…

LPI-Japanでは長期にわたりLinux技術者認定試験として「LPIC」の普及活動を行なってまいりましたが、そのお取り扱いを基本的には停止することになりました。
この度のLPICの取り扱いを基本的には停止することで、皆様に混乱とご迷惑をおかけすることを深くお詫びいたします。
すでにLPICの認定を取得された方へのサポートにつきましては、可能な限り対応をさせて頂きます。
今後のLinux技術者認定試験においては、2018年3月から提供をしておりますLinuC(リナック)をご利用いただけますよう、よろしくお願いいたします。

LPI-Japanからの大切なお知らせ – LPI-Japan

停止の理由

1. 現在配信されているLPICの試験問題は、不正流出に対する対策・対応において脆弱な状況にあります。そこでLPI-Japanは、LPICの公正性・信頼性の回復に向けた改善と、受験者・認定者の皆様に対して継続したサービス提供ができるようLPICの試験開発元であるLPI Inc.(カナダ)と交渉を続けて参りましたが、前向きな対応を得ることができませんでした。
2. 日本ではIT技術者向けの認定資格の取得を就職や昇進・昇格の条件とすることがあり、高い公正性と信頼性が求められます。この公平性および信頼性の確保のためにも、ブレインダンプ等による意図的な試験漏えいへの強い仕組み/運用体制の確保、技術の動向に沿った定期的な試験問題の更新、わかりやすい日本語による試験問題の提供が必要と判断し、LPI-Japanは「LinuC(リナック)」を独自に開発し、2018年3月より配信いたしました。
3. LPICの受験をご案内する上で必要となる受験者情報を管理するデータベースへのアクセスがLPI Inc.より2018年8月17日(金)に切断され、新たにLPICの受験を希望する方へのEDUCO-ID(LPIC専用)の新規発行、ならびにLPICの2018年8月16日(受験日)以降の受験結果のご案内ができなくなりました。

LPI-JapanによるLPICの取り扱い停止に関するお知らせ – LPI-Japan

ということで、LPI-JapanとしてはLinuCという独自の新しい試験への移行を進めているようです。

最初この説明を読んた時、”あーなるほど、LPICはLinuCに変わったのね~”という認識だったのですが、よくよく調べると…

LPICとは、LPIが主催しているLinuxの検定試験となります。全世界9ヵ国で展開されており、非常にグローバルな資格です。さらに日本だけでも、受験者数が31万人を超え、ベンダー資格としてはトップクラスに受験数が多い資格となっています。
 LinuCとはLPI-Japanが主催しているLinuxの検定試験となります。今年新しくできた資格試験であり、まだ日本のみ、及び日本市場に適応した資格を目指していくようです。簡単に言うとマイナー資格になります。

【注意】LPICとLinuC、全く別物です!(改訂版) – BrownCoder

LPI-JapanがLPIの支部となってくれることに関心を持っているならばそれでよかったのです。しかし、相談したところ関心がないことがわかりました。それでは新しい細則を展開するにあたり、自分たちでやるしかない。そうしてLPI日本支部を設立しようという流れになったのです。(一番目の記事から)
「LPI-JapanはLinux Professional Institute日本支部とは何らの関係はなく、LPI-Japanは本計画を含むLinux Professional Institute日本支部の活動に何ら関与を行っておりません」と関係性を否定。「誠に遺憾ながら、「LPIC」の実施に関する独占的権利を保有しているLPI-Japanに無断で行われたもの」であることも表明しつつ、「受験生の皆様には、より良い選択肢をご提供できるように配慮してまいります」と述べている。(三番目の記事から)

【注意】LPICとLinuC、全く別物です!(改訂版) – BrownCoder

えぇ…

ってことは結局は(現時点では)実績のあるLPIC受けた方がいいってことなんでしょうかね…

ちなみに、LPI-Japan経由でLPICを申し込むことはできなくなりましたが、代わりにLPI日本支部(ややこしい)が引き続きLPICの受験を受け付けているようです。

LPIC – LPI日本支部

ただ、公式サイトから申し込み方法ががいまいち分かりづらいです。

より分かりやすい申し込み方法が書かれている記事があったのでご紹介します。

LPICに申し込む方法について走り書き(※Linucではない) – Qiita

事情がどうであれ、資格試験で運営側のごたつきで資格取得したい側が振り回されるのはちょっとつらいですね…

  • この記事いいね! (0)
村上 著者:村上

【Xcode】「Your app supports Multitasking on iPad, so you must include the UILaunchStoryboardName key in your bundle」の対処法

今回は、Xcode で iOS アプリのリリース準備を行っていた際に発生したエラーについてです。
具体的には、Xcode で アプリを Archive し、Organizer から「Distribute App」でアプリを App Store にアップロードしようとした時ですね。

エラーメッセージは「Your app supports Multitasking on iPad, so you must include the UILaunchStoryboardName key in your bundle」というエラーで、翻訳すると「あなたのアプリはiPad上でマルチタスクをサポートしているので、あなたはあなたのバンドルにUILaunchStoryboardNameキーを含める必要があります。」とのこと。

 

ということでサクッと検索したところ、ヒットした記事がこちら。

iPad Multitaskingに対応したメモ – Qiita
https://qiita.com/jollyjoester/items/c8bb1592d01fdef663f9

上記の記事によると、iPad のマルチタスク機能に対応していないことが問題とのことです。

こちらの対処法は 2つあり、マルチタスク機能を無効にする方法とマルチタスクに対応する方法です。
今回のアプリはマルチタスク機能を無効にする方法を選択しました。

作業としては、下の画像のように、Requires full screen にチェックを入れるだけです!

強制フルスクリーンでマルチタスク自体が無効になるため、対応しなくて済む!という感じみたいです。
参考にした記事にもありましたが、こちらは手抜きの方法。
ですが、フルスクリーンで問題がないのであれば、この方法を採用してもいいと思います。

マルチタスク機能に対応する方法は、参考サイトに記載されていますので、そちらをご確認ください。

 

以上、iOS アプリを App Store にアップロードする際に発生した「Your app supports Multitasking on iPad, so you must include the UILaunchStoryboardName key in your bundle」エラーの対処法でした。
ご参考になれば幸いです。

  • この記事いいね! (0)
著者:杉浦

値オブジェクトを作った方が良い時悪い時

 値オブジェクトはエリック・エヴァンスのドメイン駆動設計 | Eric Evans, 和智右桂, 牧野祐子, 今関剛 | 工学 | Kindleストア | Amazonの中で次の様に述べられています。

あるオブジェクトが、ドメインにおける記述的な側面を表現し、概念的な同一性を持たない場合、そういうオブジェクトは、値オブジェクトと呼ばれる。値オブジェクトがインスタンス化される際に表現しようとするのは、何であるかだけが問題となり、誰であるか、あるいはどれであるかは問われないような設計の要素である。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Kindle の位置No.2480-2483). 翔泳社. Kindle 版.

 乱暴な言い方をすれば任意の型で定義されたインスタンスを実現するオブジェクトです。例えば、PHPならば次のような実装ができます。

class GeoPoint
{
    private $lat;// 緯度
    private $lng;// 経度
    
    /**
     * GeoPoint constructor.
     * @param $lat
     * @param $lng
     */
    public function __construct($lat, $lng)
    {
        $this->setLat($lat);
        $this->setLng($lng);
    }
    
    /**
     * privateプロパティを読み取り可能にする.
     * @param $name
     * @return mixed
     */
    public function __get($name)
    {
        return $this->$name;
    }

    /**
     * 一部のprivateプロパティを書き込み可能にする.
     * @param $name
     * @param $value
     * @return mixed
     */
    public function __set($name, $value)
    {
        $setter = 'set'.ucfirst(camel_case($name));

        return $this->$setter($value);
    }

    /**
     * privateプロパティにissetできるようにする.
     * @param $name
     * @return bool
     */
    public function __isset($name)
    {
        return isset($this->$name);
    }

    /**
     * 存在しないメソッドが呼ばれたらnullを返す.
     * @param $methodName
     * @param $arguments
     * @return null
     */
    public function __call($methodName, $arguments)
    {
        return null;
    }

    /**
     * __setで呼ばれるprivateプロパティへのsetter
     * @param $value
     */
    private function setLat($value)
    {
        if (-90 < $value && $value < 90) {
            $this->lat = $value;
        }
    }

    /**
     * __setで呼ばれるprivateプロパティへのsetter
     * @param $value
     */
    private function setLng($value)
    {
        if (-180 < $value && $value < 180) {
            $this->lng = $value;
        }
    }
}

 上コードならば緯度経度で地点を表現するオブジェクトです。インスタンス化時、プロパティ変更時に必ずsetHoge()を通し、setHoge()の中で不適正な値が代入されることを防ぎます。例ならば緯度は必ず-90度から90度の範囲であるし、経度は-180度から180度の範囲と限っています。setに失敗したら何も起きない作りですが、もっと厳格に作って、失敗したら即座に例外をthrowするのも全然ありです。
 値オブジェクトは極端なカプセル化の実現です。上記コードの様に好き勝手ルールを増やしても外からはルールは変えられず、見えません。必要なプロパティだけが見えます(キャストとか便利コンストラクタとかもありな気がします)。
 上記の例は緯度経度のみのざっとした作りですが、プログラムで扱う領域に複雑な概念や特殊な値の振る舞いがある程、値オブジェクトは強力になります。
 値オブジェクトを導入していないコードで値オブジェクトを導入した方が見通しがよくなる時、よくならない時があります。よくならない時は単純な種類のデータを扱っている時です。上の例にある通り、ちょっとしたものでも数十行コードが増えます。増えた分読みにくくなります。よくなる時は色々ですが、同じキーセットの配列やオブジェクトが至る所で現れるコードはよくなりやすいです。そういった時は特定のキー名で同じ概念を表現していることが多いです($hoge[‘lat’], $hoge[‘lng’]で検索すると恐ろしい数が出たり)。そういったキーをそのままプロパティにしてプロパティに適したルールをつけるだけで安全で読みやすいコードになります。

  • この記事いいね! (1)