frasco.iofrasco.io 2024 著作権. 不許複製 プライバシーポリシー
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える - pospomeのプログラミング日記
devfest 2017 tokyo の発表資料です。 Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える from pospome 当日は入室できない人もいたらしい & 機材トラブルで10minほど開始が遅れてしまった ということで申し訳なく思っています。 また、立ち見する価値がある内容を提供できたのだろうか? とも思っています。 スライドは単体でも発表内容が伝わるように文章を多めに載せているので、 是非確認してみてください。 100ページ越えていますが・・・。 #DevFest_room2 入れなかった。。— t.junichi (@tjun1) 2017年10月9日 ものすごい立ち見人数 #Devfest17 #DevFest_room2— バトルプログラマー柴田智也@少女終末旅行 (@tomoya_shibata) 2017年10月9日 ルーム2これから並ぶ方はま
Markdownエディタを作って月15万円稼ぐためにやったこと — Inkdrop
自分でもびっくりしてるいぬさん僕はフリーランスをしながら脱受託を目指してアプリを作って生活しています。だいたい1年のうち7割ぐらいをアプリ作りの時間に充てています。本稿では、Inkdropというマルチプラットフォーム対応のMarkdownエディタを一人で開発して月15万円の売上を達成するまでにやった事を包み隠さずにシェアしたいと思います。 Inkdropの月間売上の推移やったこと概要毎日感じるちょっとした問題を見つける自分自身がこれだ！と思えるまでプロトタイプを作るプライベートβ期間でヘビーユーザを作る継続性を重視して価格をつける決済処理はStripeで楽に実装する良いランディングページを作るユーザサポートを最優先にする自分の得た知見を惜しまずブログに書くクオリティで勝負する批判を全て無視する毎日感じるちょっとした問題を見つける僕は別に特別でもなんでもありません。人は意外と同じ事を感じたり
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
Go で API サーバーを開発してきて1年が過ぎました | カメリオ開発者ブログ
白ヤギの開発者の森本です。 白ヤギでは Go 言語でニュース記事のキュレーションをする カメリオ API というサービスを開発しています。約1年2ヶ月前、Go を使って開発し始めたときに当時調べた内容を整理して以下の記事を書きました。 Go言語で API サーバーを開発する 1年以上に渡り開発を継続してきて変わったこと、変わってないことなどをざっくばらんにまとめてみます。たまたま過去の記事のはてブコメントを見返していて 以下のコメント を見つけました。 最近 golang 導入事例増えて来たけど、導入後一年くらいのメンテナンスフェーズな事例について聞いてみたい。継続的デリバリーみたいなの。まだ早いのかな？ まだまだメンテナンスフェーズにはなっていなくて現在も活発に開発中ですが、継続的デリバリーについて白ヤギでは特別なことをしてなく、ansible を使ってデプロイしているのみです。Go 1
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
機械学習のためのPython入門 クラスとメソッド編 - Beginning AI
機械学習にどのようなPythonの知識が必要かは、Python機械学習プログラミングの監訳者福島 真太朗（ふくしま しんたろう）さんが以下のように述べられています。 Pythonの文法については、リスト、タプル、ディクショナリなどの基本的なデータ構造、forループ、print関数、zip関数、enumerate関数、関数やクラスの作成方法などが理解できていれば十分です。 thinkit.co.jp そこで今回はPythonで書かれた機械学習のコードを読めるように、リスト、タプル、ディクショナリなどの基本的なデータ構造、forループ、print関数、zip関数、enumerate関数、関数やクラスの作成方法について学んでいきます。 従ってこの記事は、Pythonを一度もやったことがなく、機械学習のためにPythonを学びたいという人向けです。 今回読み解くPythonコードについて 今回は題
リスペクトがない人はOSSから排除するしかない
Question regarding writeboost and MYSQL · Issue #146 · akiradeveloper/dm-writeboost · GitHub 最近ライトブーストを試し始めたユーザだが、他人に対するリスペクトがないため「お前の質問には一切答えない」と言って打ち切った。出来るだけそういうことはしたくなかったため、過去に同様のことをした時は忠告する程度に止めていたが、再発したため追放することとした。(Issue 141でも同様に、foolなど罵る言葉を使っていたため忠告した) OSSでは、会ったこともなく、それこそ本名も知らない人がコミュニケーションをとることになる。言語は英語だが、お互いにネイティブである方が稀である。そこで大事なのは、他人をリスペクトする気持ちだ。まじでリスペクトする必要はない。本当にリスペクト出来ないなら去ればいいだけだし、リスペ
PHPからScalaに乗り換えたチャットワークさん、その後どうですか？（前編） | HRナビ by リクルート
本当にScala化できるんですか？ 増井：今日は、チャットワークをPHPからScalaに切り替えるお話を伺うためにやって来ました。 山本：はい。 増井：僕がこの話を知ったのは、ちょうど2年ぐらい前に読んだブログのエントリだったんです。いきなり失礼なんですが、僕はこの話を知って、ぶっちゃけアホじゃないかと思ったんですよ。 山本：あはは（笑） 増井：基本的に開発言語やフレームワーク、方法論を同時に変えるって結構大きな変更ですよね？ 山本：そう思います。 増井：それなのに、この決断を発表された当時、御社にはScalaエンジニアがいなかったそうじゃないですか。「本当に大丈夫なのかな？」と思って、気になってたんです。昨年春には「Scala採用を決めて一年たった、CTOの雑感」というエントリをポストされていましたが、さらに1年経った今はどんな状況なんですか？ 山本：ひと言で申し上げると「絶賛移行中」と
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
OSS開発に参加するには？OSS開発のやり方がわかる記事10選まとめ
OSS（オープンソースソフトウェア）開発への参加実績は、キャリア形成をしていく上での武器のひとつとなります。 スキルアップやキャリアアップのために、オープンソースプロジェクトに参加したいと考えている方は少なくないのではないでしょうか。そこで今回は、既存のOSS開発に参加する際に読んでおきたい記事を10個ご紹介します。 OSS開発の参考になる記事 OSSコミュニティの種類と特徴、参加方法 / 日本OSS推進フォーラム http://ossforum.jp/node/491 日本Rubyの会、Seasarプロジェクト、日本Apacheユーザ会、日本PostgreSQLユーザ会といったOSSコミュニティの種類と特徴、コミュニティへの参加方法を解説しています。 この記事を参考に、自分が貢献できそうなコミュニティを探してみてください。
Pythonで少なくメモリを使用する方法 - のんびりしているエンジニアの日記
皆さんこんにちは お元気ですか。私は元気です。 今日はPythonにおけるメモリ少なく使う方法を紹介したいと思います。 なぜ、そんな方法を書くに至ったか。それは、こんなエラーをしょっちゅう見ているからですね。 Traceback (most recent call last): File "lasagne_wheal.py", line 48, in <module> prediction = model.predict_proba(np.array(X_test)) MemoryError 画像処理を行っている人間ならよくやりがちかもしれませんが、 要はint8で持っている情報をfloatに変換してデータが膨れ上がったことによってメモリが 不足していることから発生しています。 Convolutional Neural Networkを大きな画像で実施しようとするとよく発生するのではないで
Androidソースコードレビューで指摘する事が多い項目まとめ2 - こやまカニ大好き
去年Androidソースコードレビューで指摘する事が多い項目まとめという記事を書いた時はアプリ全体を一度に見るような機会が多かったため、内容も大きめのものばかり書いていましたが、最近はプルリクエスト単位でレビューする機会が増えたので細かい項目についてまとめてみようと思います。 ミリ秒で時間を指定する時に自前で計算している 1000L * 60L * 60L * 24Lのようなコード。 TimeUnitを使いましょう。 24時間の場合は以下のように書けます。 TimeUnit.DAYS.toMillis(1L) ある文字列がhttp/httpsで始まるかチェック URLUtil.isNetworkUrl()を使いましょう。 ただしequalsIgnoreCaseで判定してます。 ベースURLにパラメータを付与していってURLを生成したい StringBuilder#append("&key=
Obj-C → Swift コンバータをオープンソースで公開しました！
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog どうも、ヤフーの佐野（ @taketo1024 ）です。先日引っ越しをしまして、張り切って自分でタンスを運んだりして今とても筋肉痛です。 皆さんは Objective-C から Swift への移行は進んでいますか？弊社ではまだ Obj-C で書かれているプロジェクトは多くあります。世に出ている iOS アプリも多くはまだ Obj-C で作られているんじゃないかと思います。 Swift もオープンソース化され、この先その進化のスピードはさらに増してくるはずです。そこでチーム内で開発を進めていた Obj-C → Swift コンバータ を大幅に改良しオープンソースで公開することにしました！この記事ではその導入と活用の方法を説明します
Sledge ドキュメント - にぽたん研究所
先日の Shibuya.pm テクニカルトーク #6 で、やっぱり注目のフレームワークは Catalyst なんだなぁーって思いつつ、日頃から Sledge を使っているせいか、あまり良さや真新しさを感じなかったりして。 「メタフレームワーク」という存在定義っぽいので、Catalyst のそれ自体は割と貧相。 なのに Helper まわりとかは妙にゴージャス & 拡張されているので、やる事や Model が決まってればすぐに使え、そうじゃない場合はすぐ使えなさそう。 Rails の対抗馬なのかも知れないですが、Rails な人が wink とか使ってアジャイル開発とか言って見せびらかしているようなのを真似するには向かないかも知れないですね。 まぁ Sledge も Model に制約がなかったりするのでまず向かないですが「10 分でブックマーク作れ」とか言われたら出来るかも知れん。 Cat
Pythonのオブジェクトとクラスのビジュアルガイド – 全てがオブジェクトであるということ | POSTD
Python開発者が大好きな言葉があります。それは”全てはオブジェクトである”です。実際、私自身もPythonのクラスを教えているときに何度も口にしています。多くの人が何度も聞いた言葉かもしれないのですが、私が言う度に生徒は賛同の相槌をしてくれます。結局のところ、Javaにおいて全ては（対象がそうでない場合を除いて）オブジェクトであり、.NETにおいても全てはオブジェクトであると、よく言われています。 しかしPythonにおいて全てがオブジェクトであると言う時、（私の生徒は驚いていましたが）「 全て 」にはクラスも含まれているのです。これはとても筋が通っていて、オブジェクトシステム全体が理解しやすくなります。しかしそれでも、広い視野で物事を見ることは難しいのです。 今回のブログ記事では、Pythonのオブジェクト間のつながりをざっと見ていきたいと思います。そして”全てはオブジェクトである”
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
Python のバージョン毎の違いとその吸収方法について - CUBE SUGAR CONTAINER
この記事の目指すところ 現在 Python はバージョン 2.x 系と 3.x 系という、一部に互換性のないふたつのメジャーバージョンが併用されている。 その上で、この記事にはふたつの目的がある。 ひとつ目は、2.x 系と 3.x 系の違いについてまとめること。 現状、それぞれのバージョン毎の違いはまとまっているところが少ない。 自分用に、このページだけ見ればひと通り分かる！っていうものがほしかった。 ふたつ目は、2.x 系と 3.x 系の違いを吸収するソースコードの書き方についてまとめること。 こちらも Web 上にナレッジがあまりまとまっていない。 これについては今 python-future というパッケージがアツい。 尚、サポートするバージョンは以下の通り。 2.x 系: 2.6 と 2.7 3.x 系: 3.3 と 3.4 本題に入る前に、最近の Python 事情についてまとめ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いデバッグログはプロジェクトの資産である
物理サーバを選定する際のポイント – Eureka Engineering – Medium
