先日発表した私の処女作 SYNTHESIZE ですが、30歳から漫画を学びはじめてアウトプットした作品となります。 一応どういうふうに漫画を学んだのかに関しては、 SYNTHESIZE 1話目の創作ログ に纏めてあるので興味がある方はこちらも読んで頂ければと思うのですが、個人的な漫画勉強法に関してもっと具体的に、画像つきで、詳細を語りたいと思います。 ※画像は冨樫義博「HUNTERxHUNTER」より引用 HUNTERxHUNTERを徹底的に考察する まず、こちらの本 Filmmakers Eye 映画のシーンに学ぶ構図と撮影術：原則とその破り方 を読んで、基本的にバストアップやエスタブリッシュショットにどういう意図があるのかを知識としてインプットしました。 次に自分にとって「これは最高傑作である！こんな作品が描きたい！」と思えるような漫画（私の場合はHUNTERxHUNTER）を引っ張り

SYNTHESIZEという漫画の連載を、自分で作ったサービスLeth（このエントリーを掲載しているサービスそのもの）で始めました。 普段は普通のサラリーマンをしたりしています。3年くらい前まではエンジニアをやっていた気がしますが、色々あって今は仕事でコードは書いていません。 今（2018/9月時点）私は33歳なのですが、29歳の終わり頃でしょうか、ふと「漫画でも描いてみるか」と思い立ってから今日こうして無事公開できるに至るまでの話と、今後の展望の話を書き残しておきます。 動機の話 私は20代の半分程をエンジニアとして過ごしていました。幸いデザインも好きだった事もあり、昔から余暇の時間を利用していくつか個人でサービスをリリースしたりしていました。それまでの人生は音楽づくしであったし、「創作」そのものが好きなんだと自己分析しています。プログラミングも創作の一つだと捉えていますし。絵を描くのも好

Quipper に入社して丸3年が経った。そんなことすっかり忘れていた。3年と言われてもピンとこない。体感的にはものすごく昔のことのように感じられる。それだけいろいろあって濃い日々を過ごせたということだと思っておこう。 せっかくなので、 Quipper 日本オフィスの変遷になぞらえながら振り返ってみる。 入社前夜 前職で担当していたサービスの事業展開がうまくいかず、英語を使う環境で仕事をしてみたいという希望もあり、海外スタートアップ企業への転職を考えはじめたのが2013年の3月だった。 3月上旬にWantedly で見つけた Engine Yard のソフトウェア開発者募集に応募して選考に進んだものの、合否がなかなか出ず、やきもきしていた頃に前職の同僚で同じサービスをペアで開発していた @banyan に「Quipper に転職するんだけど話聞いてみない？」と誘われたのが4月の半ば（たしか

お世話になります、フロントエンド担当をしている小原正大です。Webページの表示を監視して差異があった場合、どのページで表示の変化が起きているかを知ることが出来るプログラムを実装したのでそのことについて書こうと思います。 何につかったの？ 僕がフロントエンドを担当しているサービス『料理サプリ』で大規模なフロントエンドコードのリファクタリング行う際に表示テストを自動化するために作成しました。『料理サプリ』はPC・スマホ合わせて大体350-400ページの表示パターンが存在する比較的規模の大きいサイトです。全ページに影響を与えるような作業は大規模な回収となり、今回のリファクタリングでは表示テストの計画などの段取りが必要でした。従来の人手によるQAでは細かいバグを見過ごしたり時間がかかり効率が悪いので、可能な限り自動化しようと考え実装しました。 実装の概要 この監視のシステムは以下の２つ実装を組合わ

HTMLをクライアント側でちょっとパースする要件にてiOSで使えるHTMLパーサを調べると、いくつかあるのですが、HTMLReaderというのがたまたま目につきました。 // Bridge-Headerにて、HTMLDocument.hとHTMLSelector.hをインクルードしてる import UIKit import Alamofire class ViewController: UIViewController { @IBOutlet weak var textView: UITextView! override func viewDidLoad() { super.viewDidLoad() let req = request(.GET, "http://number.bunshun.jp/articles/-/821939") req.responseString { (_,

中小企業に関する白書や統計情報の一覧です。中小企業の数や基本データ、景気情報、製造業の生産指数、倒産状況、産業連関表など、中小企業に関する様々なデータを掲載しています。

【寄稿】 オランダのコミュニティケアの担い手たち（前編） 在宅ケアのルネサンス――Buurtzorg 堀田聰子（労働政策研究・研修機構　人材育成部門研究員） オランダは，1968年に世界で初めて長期ケア保障について普遍的な強制加入の社会保険制度（特別医療費保険）を導入した。プライマリ・ケアを重視し，保険者機能の強化と管理競争の導入により，効率的な短期医療保険制度運営を行っていることでも知られる。Community-based care（地域を基盤としたケア）とintegrated care（統合ケア） という2つの独立したコンセプトを統合させて組み込もうという議論が世界的に活発化するなか，オランダは，実際に両者のコンセプトを含んだシステム構築を試みた数少ない国とされる。 本稿では，オランダのコミュニティケアの担い手として注目を集める2つの組織における取り組みを前・後編に分けて紹介する。今回

あと、やはりネットワーク周りなどI/Oの多いプログラムの書きにくさが課題になっている印象。関数的なI/OはFRPで解決できそうな気がするんだけど調べてない。そろそろFRPをちゃんと理解したいなー。 Parsec 3活用事例: Keepalived構文チェッカ - maoeのブログ なんて書いてから早1ヶ月半、ようやくFRPが掴めてきたのでわかったことをまとめてみます。 Reactive programmingって何？ FRPの前に、一般的にwikipedia:en:Reactive programmingと呼ばれるパラダイムについて触れておきます。reactive programmingとは疑似言語を使ってかなーり大雑把に説明すると、 var a = 1 var b = a + 1 a = 10 // aを書き換える print b // => 11print bの出力は2ではなく11です

© Valve Corporation. All rights reserved. All trademarks are property of their respective owners in the US and other countries. Privacy Policy |  Legal |  Steam Subscriber Agreement |  Refunds

A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team

昨日の夜, 承認欲求をアウトソーシングして外部の人間に任せているのは不安要素が多いのでBOTがやるべき仕事だと思って, 久しぶりに夜更かしして承認くんを作った. https://twitter.com/ShouninJp フォローしておくとたまに承認してくれる. 承認くんはAPIも用意されていて, 承認単語の登録・削除・一覧の機能を備えている. # 登録 $ curl http://www.shounin.jp/vocabularies -X POST -d 'text=これが才能か...' # 削除 $ curl http://www.shounin.jp/vocabularies/1 -X DELETE # 一覧 $ curl http://www.shounin.jp/vocabularies 誰でも自由に承認くんに単語を覚えさせたり出来るのでよろしくお願いします.

最近，C++ の crow という薄いウェブフレームワークが出ました．特に要件は書いていないですが，C++11 以上が必須のモダンな設計で Python の Flask のような雰囲気で書けるのが売りらしいです． ipkn/crow CROW_ROUTE(app,"/hello/<int>") ([](int count){ if (count > 100) return crow::response(400); std::ostringstream os; os << count << " bottles of beer!"; return crow::response(os.str()); }); このように，ルートを指定し，それに対する処理をラムダ式で書くようです．ルート指定内にあるタグに対応した引数を取るラムダ式を指定します． examples の中にはありませんが，"/users

おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ