タグ

volonteのブックマーク (1,298)

  • Large Scale Laravel Application

    Lets face it! Maintaining large PHP application is not easy. (Click here if you just want to see the solution) We all know that, Laravel is the most popular PHP framework till today. It’s directory structure is good, well organized, defined and straight-forward. Working with the default project structure provided by Laravel is absolutely fine when we are working in a small or medium sized project.

    Large Scale Laravel Application
    volonte
    volonte 2017/11/17
  • Adding and Removing Child View Controllers | CodePath iOS Cliffnotes

    Adding and removing child view controllers ensures that the parent view controller knows of its children. This will help when doing things like calling a modal from a child view that has been added to the parent. This behavior can be buggy if the parent doesn't know that it's connected to the child. Another reason is so that viewWillAppear, viewDidAppear, viewWillDisappear, and viewDidDisappear wo

  • kyanny のブログ : nowa 最後の日

    2009年03月31日23:59 カテゴリ nowa 最後の日 今日、 nowa がサービスを終了し、二年弱の短い歴史に幕を下ろした。 nowa について「中の人」が何か書くのは sasakill 曰く「愚か者」のすることだそうだが、俺は愚か者なので感想を書くことにする。なお、以下に書いてあることは単なる感想と回顧録です。特定の誰かを批判、非難する意図はありません。 nowa に関わったスタッフは、たぶん俺はあまり出来がいいほうじゃなかったと思うけど、それ以外の皆さんは各々がとても良い仕事をしたと思います。特に開発に携わった人たちはすごかった。俺はその人たちが書いたソースコードを毎日読んでいたので、そのすごさは良く覚えています。 nowa は俺がライブドアに入社して最初の秋冬にスタートした。最初は「PRAC(仮)」というコードネームで、これが何の略だったかはもう忘れた。「livedoor

  • nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた?(下)

    March 10, 201213:50 カテゴリライブドアという会社の話をしよう ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた?(下) さて、前回からの続き。 社運をかけて招集された nowa の開発チームは、プログラマ、ディレクター、デザイナー、マークアッパ、どれをとっても精鋭チームというべき豪華な面子が勢揃いしていた。 一方の「旧ブログ」チームは、それまで一人でブログを支えて続けていたベテランのエンジニアが辞め、あとを僕ともう一人とで継いだものの、その片方の人も別会社に移って行ってしまって、エンジニアは僕一人だけになっていた。マネタイズのプランもなくただの金い虫だった「旧ブログ」には大した長期戦略も与えられず、広告営業案件の狩り場と化して、宣伝用のブログパーツばかり作らされていた。 基的に旧ブログチームの役割はデ

    nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた?(下)
    volonte
    volonte 2017/11/15
    [新システム]
  • 書き直したって、いいんだよ

    http://www.yamdas.org/column/technique/hatenablog.html なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた(ソフトウェア企業)が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か? プログラムをスクラッチから書き直すことに決めることだ。 まぁ、そんなわけないんだけどね。 「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試

    書き直したって、いいんだよ
  • はてなは「絶対すべきでないこと」をやらかしたのか?:後記 - YAMDAS現更新履歴

    はてなは「絶対すべきでないこと」をやらかしたのか?は、サイトに5年近くぶりに公開する技術コラムだったのでそれなりに気合いを入れて書いた文章だったが、まさか自分が過去書いたり訳したどの文章も超えるはてなブックマークを1日足らずで集めたのには驚いた。「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章という誉め言葉をいただいたのはともかく(皮肉でなく、当にそれだけだったら素晴らしいと思うので)、サッカーのフロントにあてはめた文章まで出るとは思わなかった。情報を加える後記を少し書かせてもらう次第である。 まずその前に、はてなブログについてチーフエンジニア兼ディレクターの大西康裕さん(id:onishi)が行ったプレゼン資料「新はてなダイアリーの裏側」が公開されていることを id:laiso さんにブックマークコメントで教えていただいた。はてなブログについて論じる上で、こうした

    はてなは「絶対すべきでないこと」をやらかしたのか?:後記 - YAMDAS現更新履歴
  • 伊藤直也氏×大場光一郎氏に聞く「レガシーなアーキテクチャの見直し方」スケールのカギはHacker Wayな文化が握る【特集:1を100にする開発戦略】 - エンジニアtype

    伊藤直也氏×大場光一郎氏に聞く「レガシーなアーキテクチャの見直し方」スケールのカギはHacker Wayな文化が握る【特集:1を100にする開発戦略】 タグ : KAIZEN Platform, アーキテクチャ, クラウドワークス, 伊藤直也, 大場光一郎 2015/06/10公開 ゼロイチのフェーズでスピード感を持って書いたコードが、さらにスケールするフェーズになって負債としてのしかかるという話をよく耳にする。 そうだとすると、サービスをスケールしていくためには、どこかのタイミングでアーキテクチャを設計し直さなければならないのか。あるいは、最初から緻密に設計されたアーキテクチャの下に開発するのが筋なのか。 Kaizen Platform技術顧問の伊藤直也氏、クラウドワークスCTOの大場光一郎氏は肩書きこそ違えど、ともに「ゼロイチ後」の成長期に加わった「イチヒャク」の請負人であるということ

    伊藤直也氏×大場光一郎氏に聞く「レガシーなアーキテクチャの見直し方」スケールのカギはHacker Wayな文化が握る【特集:1を100にする開発戦略】 - エンジニアtype
  • ドメイン駆動設計: Aggregate実装チェックシート - Qiita

    ドメイン駆動設計でAggregate(集約)を実装するためのチェックシートです。 □ トランザクション分析をしてトランザクションの単位でAggregateを実装しているか? 単にツリー構造や分類学的にAggregateを作っているとしたら正しくない。 Entityを複数含むAggregateを作っている場合は、トランザクション分析していない可能性があるため、 ユースケースを確認しビジネス上のトランザクション分析を行う。 □ Aggregateの大きさは大き過ぎないか? もし、Aggregateが複数のEntityを含んでいる場合は、 EntityをValue Objectにすることができないか、 直接参照ではなくEntityをAggregate Rootに昇格しIDによって参照する設計にできないかを検討する余地がある。 □ 他のAggregateは直接参照ではなく、IDによって参照されてい

    ドメイン駆動設計: Aggregate実装チェックシート - Qiita
    volonte
    volonte 2017/11/02
  • PDOの真の力を開放する - PHPでデータベースを扱う(3)

    ちょっと遅れましたが、シリーズの第3回です。前回までに論じた内容をふまえて、簡単な実装を示します。↓前回までの内容はこちら。 DAOの悪夢 - PHPでデータベースを扱う(1) - 泥のように ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2) - 泥のように 題材 「記事にタグを設定できるブログ」みたいなシステムを考えてみます。ブログ記事を示すEntryテーブル、タグを表すTagテーブルの二つを用意しました。MySQL WorkbenchによるER図(鳥足記法)は以下になります。 1つのEntryに対して複数のTagがある、1対多の関係です。同じTagが複数のEntryに関連するため、多対多の関係と見なすこともできそうですが、タグ程度だとあまり意味がないので、これ以上のテーブル分割はやめておきます。 Entryテーブルの主キーがentryIdと冗長な名前をしているのは、自

    PDOの真の力を開放する - PHPでデータベースを扱う(3)
    volonte
    volonte 2017/11/02
  • ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2)

    Userテーブルに対してデータをinsertするメソッドを考えます。愚直なこんなインターフェースはどうでしょうか? class UserMapper { //... function insert( $nickname, $password, $firstname, $lastname, $birthday ) { //... } } …この引数を覚えていられる人はそう多くないと思います。もしプログラムを間違えて、nicknameとfirstnameを逆に指定してしまったら、名がnicknameとして登録されてしまいます。名が誤って表示されてしまうという致命的な事故につながります。危なっかしいプログラムですね。 では、順番を考慮しなくていいように連想配列にすればどうでしょうか? class UserMapper { //... function insert(array $data)

    ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2)
    volonte
    volonte 2017/11/02
  • DAOの悪夢 - PHPでデータベースを扱う(1)

    最近、昔の自分が書いたコードをメンテしているのですが、何というか、「ええい、誰じゃこのコードを書いたのは!!」と叫んでは「…4年前の俺でした…」とセルフツッコミを繰り返しています。すごく読みにくいコードで、ストレスたまりまくりです。そのため、「今ならどう書くか」をよく考えました。ちょっと長くなるかもしれませんが、アンチパターンとして解説したいと思います。 DAOパターンについて 私が々としてメンテしているコードですが、データベースとのやり取りを行うためのクラスです。当時意識していませんでしたが、改めて見ているとDAOパターンを再現しているものでした。 DAO(Data Access Object)とはデザインパターンの一種で、データベースへのアクセスロジックを集約したクラスのことです。有名なGang of Fourによる23種の基デザインパターンには直接含まれていませんが、Facade

    DAOの悪夢 - PHPでデータベースを扱う(1)
    volonte
    volonte 2017/11/02
  • A modern REST API in Laravel 5 Part 1: Structure - Esben Petersen

    A modern take on a scalable structure for your Laravel API Posted by Esben Petersen on April 11, 2016 tl;dr This article will demonstrate how to separate your Laravel project into "folders-by-component" rather than "folders-by-type". Confused? See the example here or the library here. Introduction Over time when your API grows in size it also grows in complexity. Many moving parts work together in

    A modern REST API in Laravel 5 Part 1: Structure - Esben Petersen
    volonte
    volonte 2017/11/02
    レポジトリパターン
  • 特定の条件で rootViewController を差し替えるとメモリリークする件 - NANAIRO

    UIApplication.shared.keyWindow?.rootViewController で画面を差し替えたい時がありますよね? 例えばどんな時があるかとかと言いますと 認証画面があり signup/signin 後に画面を切り替え sigup/signin 後にチュートリアルの画面を表示 signout 後に認証画面を表示 などがあるかなと思います。 タイトルの通り、とある条件を満たして rootViewController を切り替えると差し替える前の viewController が解放されずに残り続けてしまいます。 これは iOS8 頃から認識していた問題ではありますが、iOS10 現在になっても修正されていません。 rdar://21404408: Memory leak in iOS 8+ after setting window.rootViewControlle

    特定の条件で rootViewController を差し替えるとメモリリークする件 - NANAIRO
  • 【swift】ログイン・ログアウト処理 - とりあえずphpとか

    はじめに 今回やりたかったのは、ありがちなログイン・ログアウト処理。 初回起動時にログイン画面を表示。1度ログイン後は次回起動時にもログイン画面は表示しないということ。 方法としてはuserDefaultsという端末のストレージにログイン状態を保存しておくというやりかたになります。 実装方法 AppDelegate まずは起動時の処理をAppDelegateに記述します。 userDefaultに値isLoginがセットされていればログイン中用のMemberViewControllerを表示。 セットされていなければ未ログイン用のVisitorViewControllerを表示。 AppDelegate.swift class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? var naviga

    【swift】ログイン・ログアウト処理 - とりあえずphpとか
  • Laravel 5.3でREST APIのテストコードを書く - Qiita

    2016-02-19 追記 Laravel5.4がリリースされテスト周りの書き方が大きく変更されています。 この記事の内容だとLaravel5.4では動作させる事が出来ません。 時間が出来次第、この記事にLaravel5.4でも動作するように編集します。 (参考) https://laravel.com/docs/5.4/testing http://qiita.com/komatzz/items/1679373c86c252c5f49f この記事で伝えたい事 テストコードを書く事により得られるメリット テストコードを書く時上で必要な考え方 REST APIでの具体的なテストコードの書き方 仕事Laravel 5.3を触る機会があったので今回のサンプルではLaravel 5.3を利用します。 とはいえテストコードの基的な考え方は他の言語やフレームワークでもほぼ同じですので、他の言語でも

    Laravel 5.3でREST APIのテストコードを書く - Qiita
  • ytake.blog | PHPUnitの設定は正しくしよう

    PHPUnitの設定は正しくしよう Posted: 2015-03-22 22:10 | laravel PHP全般 題の前に一つ Laravel5のサンプルアプリケーションですが GitHub にて公開しています。 「laravel5になって名前空間が強制される」、「移行が大変」 ネット上でよく見かけますが、全くそんなことはありません。 composerのオートローダ指定の方法が異なるだけで、根的には全く変わりません。 公開しているサンプルアプリケーションは、 5の新機能のいくつかを使って、 ・マークダウンエディター(Laravel5 + React.js) ・簡単なToDoアプリケーション(Laravel5 + React.js) ・Laravel4と同様にclassmapを指定して名前空間を利用せずに実装した簡単なフォーム 上記3つが実装してあります。 React.jsも利用して

  • ytake.blog | Laravel/データベースレイヤーとのテスト2

    Laravel/データベースレイヤーとのテスト2 Posted: 2015-05-25 03:03 | laravel PHP全般 Laravel/データベースレイヤーとのテスト1 の続きシリーズです データベースを利用するクラスの疎結合とファンクショナルテスト時のバインディング変更方法を簡単に紹介しました。 ではデータベースを利用したクラスをユニットテストを行いたい場合はどうするのでしょうか! このクラスでテストしたいものは、データベースに正しく値が書き込まれるかどうかではなく、 意図したSQLが発行されているかどうかなどでしょう。 実際にテストしてみましょう。 実際のデータベースを利用せずにテストするには、sqliteを利用する方法が一般的です。 テスト用にsqliteのファイルを作成しても構いませんが、ここではsqliteのインメモリ機能を利用します。 テストでデータベースの接続先を

  • ytake.blog | Laravel/データベースレイヤーとのテスト1

    Laravel/データベースレイヤーとのテスト1 Posted: 2015-05-23 23:11 | laravel PHP全般 5.1が目前ですが、Laravelアプリケーションのテストやってますか? 便利な機能がたくさんあるなかでも、一番人気があるのはEloquentでしょうか? Eloquentを用いたアプリケーションでのテストについていくつか紹介しましょう。 データベースなどを用いた値などのデータレイヤー(リポジトリ、エンティティなど)の実装を シンプルに、ドキュメントなどにある例で実装してみましょう。 (エントリではモデルという抽象的な表現は用いません。MVCアーキテクチャ一辺倒の内容ではないからです) 一般的な実装例 マイグレーションファイルとして下記のように作成します use Illuminate\Database\Schema\Blueprint; use Illumi

  • https://altarf.net/computer/swift/3543

    https://altarf.net/computer/swift/3543
  • Debugging Firebase Cloud Messaging on iOS

    Debugging Firebase Cloud Messaging is one of the most common Firebase-on-iOS questions I see on StackOverflow. And so in an effort to garner as many StackOverflow points as I can (oh, yeah, and to educate the developer community), I thought it might be helpful to write up a full debugging guide on what to do when you can’t seem to get Firebase Cloud Messaging (FCM) working on your iOS device. Firs

    Debugging Firebase Cloud Messaging on iOS