Search, watch, and cook every single Tasty recipe and video ever - all in one place! News, Politics, Culture, Life, Entertainment, and more. Stories that matter to you.
[Pythonでも型チェックが捗る]と噂をきいたのでPHPの環境構築について書きます。ちょっと眠いので簡潔に… もしわからないことがあったら回答するのでコメントで聞いて1。 得られる利益 関数名を間違ってることに気付いたり 変な型どうしで計算してることに気付いたり うっかり変な値をreturnしようとしたり そんな問題に編集中に気付けるよ。 画面はVimだけど、ほかのエディタでもいいよ。 事前準備 PHP 7.1+ macOSなら brew install php とかでもいいです (システムに最初から入ってる/usr/bin/phpは不可) Composer https://getcomposer.org/download/ とか読んで適当に入れて。 COMPOSER_HOMEにPATHを通す PATH=$HOME/.composer/vendor/bin:$PATH みたいな行をシェル
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私は現在、Scalaで書かれているわりと古めのゲーム用サーバーに、いろいろ機能追加したり不具合修正したりする仕事をしています(オマケとして、Nodeで管理ツール(イベントやお知らせの編集、プレイヤーの個別情報の閲覧や設定)やKPIツール(各種統計をとってビジュアライズする、ゲーム運用の生命線となるツール)を書いたり、PythonやGoでテストクライアントを書いたりもしています)。 このサーバーシステム、これまでのいくつかのゲームタイトルでおおむね順調に稼働していた実績を買われ、差分開発ということで別のゲームへの流用を打診いただき、ふたつ
この例では、FooBarBuilderオブジェクトがBuilderオブジェクトです。典型的にはBuilderオブジェクトのメソッドはメソッドチェーンの形で呼び出せるようになっており、foo, bar, buildはFooBarBuilderのメソッドです。 このようなBuilderオブジェクトは、間違った使い方をするとうまくいきません。例えば、(new FooBarBuilder).foo(123).build()のようにすると、barの値が指定されていないので失敗してしまうでしょう。普通にやると、そのような失敗はbuildメソッド呼び出し時の実行時エラーとして現れることになります。 しかし、型がある言語においては、このような失敗を実行時エラーではなくコンパイル時の型エラーとして検出したいという欲求が発生します。すなわち、型安全なBuilderパターンです。実際、既にRustやC#などで型
GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。 GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。 ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。 Resource page for reposurgeon 3.44 しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。 ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。 GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix ESRの所有する64GBのメモリ
経済産業省は2016年、「IT需要が拡大する一方で、国内の人材供給力が低下し、IT人材不足は今後より一層深刻化する可能性があります」とホームページ上で発表している。発表から2年以上が経過した現在も、採用担当者から「エンジニアの採用が喫緊の課題です」と聞くことが増えた。 また、エンジニアには“エンジニア独自の文化”があるとも言われており、仮に採用することができても、文化を理解しなければ円滑なマネジメントは難しい。特に人材不足が嘆かれる急成長中のスタートアップにとって、エンジニアの採用とマネジメントは成長を加速するための最重要課題といっても良いだろう。 そうした状況を受け、グロービス・キャピタル・パートナーズ(以下、GCP)では、投資先の企業に向けた「エンジニアの採用とマネジメント支援」を行っている。マネジメント支援を担当するのは、GCPが顧問契約を締結する及川卓也氏だ。 及川氏はマイクロソフ
ハロー、@seto_hiです。 北海道で避暑をしています。 アプリ開発をしていると様々なコンバージョン率がKPIになることは多いですが、誠実さを欠いたUIを作ると数字がよく伸びることが稀によくあります。 そういったものは一時的な利益には繋がりますが、長期的な利益には繋がらないと考えています。 自分が今後そういったUIを作らないための予防線としてこの記事を書きます。 不利益の排除 ・不利益な動線を奥深くに隠す ・ユーザーが設定を変更する手間を増やす ・「メールマガジンの解除にはメッセージを送ってください」 ・「メールマガジンの解除にはログインが必要です」 ・過度に警告を表示する ・「この設定をOFFにするとアプリが正常に動作しなくなる可能性があります」 ・「本当にOFFにしてよろしいですか」 ・不利益な動線を目立たなくする ・不利益な動線のシグニファイアを消す ・スマートフォンならスクロール
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く