プロダクト | PALLET HOUSE JAPAN
前回はてぶのお気に入りフィードを読むHBFavというアプリのReactNative版RNHBFavというアプリを作っているという話を書いたが、とりあえずAppStoreへ申請するところまで終わった。 razokulover.hateblo.jp 申請がどのくらいで通るかはまだわからないが、たぶん1週間はかかる気がする。 少し時間が空きそうだし、ここらで今回ReactNativeで開発〜リリース申請する中で感じたことやこうした方が良かったみたいなものをメモしておこうと思う。 垂直分割/水平分割のディレクトリ構成 ディレクトリ構成はプロジェクトごとにみなそれぞれ自分なりの構成を持っているようだけど、例えばreduxを利用するアプリだと以下のような作りになると思う。 index.ios.js index.android.js src |__actions |__hoge.js |__reduce
こんにちは、 id:shiba_yu36 です。 先日、新しい機能や改善を加えようとする時に、それがデータベースに対して悪影響を及ぼさないか、どのように検証すれば良いですかという相談を受けました。つまり、新しく作った機能を導入した瞬間にデータベースが高負荷になりサービス全体に影響を与えたりしないか不安であるという相談です。その相談に対して僕は、簡単な計算式を作り、その機能のデータベースへの影響度をざっくり推定することで、リリース前に時間をかけずにパフォーマンスに悪影響を与えないか推定できるという話をしました。 この話をしていて、「リリースする前に新機能や改善がサービスのパフォーマンスに悪影響を与えないか素早く推定する」ことは、経験のあるエンジニアは自然とやっているけれど、あまりブログなどで言語化されていないと感じました。そこで、今回はこのことについてブログに書いてみます。 なぜ機能をリリー
こんにちは。freee 共同創業者 CTO の横路です。 freeeは現在、「スモールビジネスに携わるすべての人が創造的な活動にフォーカスできるよう」というミッションのもと、テクノロジーによる中小ビジネスのバックオフィス効率化とデータドリブンな経営意思決定支援を実現すべく、スモールビジネスAIラボチームを立ち上げて活動しています。 その中で、サービス・プロダクトづくりをリードし顧客に価値を届けてきたソフトウェアエンジニアこそ機械学習を学び、顧客の課題解決のいちオプションとして身につけはじめるべきだという実感を得たので、エンジニアリング対象としての機械学習について紹介します。 サービスをつくるエンジニアが機械学習を学ぶべき3つの理由 サービス開発で顧客に価値を届けるソフトウェアエンジニアこそが機械学習を学ぶべきだと思う理由は、以下の3つです。 サービスが対象としているトピックについて 深いド
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
ここ最近、なんというか・・・DIYづいていまして、いろいろと作ったり、作りたいなと思って計画を立てたりしています。 思えば、物を置く棚とか、箱とか、机とか、今までいろんな物を作ってきました。 いろいろと作っていると、その中であれも欲しい!これもあったら便利!と言う感じで、DIYに使用する道具も増えてしまいました。おそらく、道具関係はけっこう持っている方だと思います。 中には全然使わない道具もあるけど、いい感じに便利に愛用している道具もあります。道具や工具は、良さそう!って思うと、ついつい欲しくなっちゃうんですよねえ・・・ てなわけで、今まで使ってきて、あればDIYするときに便利だよね〜めっちゃ作業捗る!という工具や道具などを紹介していきます。 <目次> 所有していると便利な工具や道具 加工具 インパクトドライバー 卓上ボール盤 オートセンターポンチ 丸ノコ ジグソー ディスクグラインダー
piqcy @icoxfog417 言語モデルのタスクで、CNNでLSTM同等以上の精度を出したという話。畳み込んだ結果をGRUに近い機構で処理し、過去の情報が消失しないようにしている。Google Billion Wordのデータセットでは、LSTMと同等の精度を出す一方計算効率が20倍程度改善された。 twitter.com/Smerity/status… 2017-01-01 13:23:09 Smerity @Smerity Gated Convolutional Networks beat LSTM on LM (WikiText-103 & One Billion LM for single GPU), faster than CuDNN LSTM arxiv.org/abs/1612.08083 pic.twitter.com/UBplrTjEAv 2016-12-26 15
みなさん、こんにちは。Retty CTO の樽石です。 この記事は Retty Advent Calendar 25日目です。メリークリスマス。 昨日は @ttakeoka の『MFIにむけてRettyの取り組み』でした。 今年も残りわずかになりました。いかがお過ごしですか? Retty はこの 1 年でエンジニアがほぼ倍増しました。それによって、情報発信者が増え、Advent Calendar に参加出来るようになりました。みんな楽しそうにしていて、うれしいです。 Retty Inc. Advent Calendar 2016 - Qiita さて、今年最後の Retty Advent Calendar 記事を書くということで、はじめは 1年のまとめ的内容にしようかと思いましたが、それでは平凡で面白くありません。そこで、ネタになりそうなマニアックな技術的記事で締めくくりたいと思います。
この記事は、去年私が書いた「Machine Learning in a Week(機械学習に挑んだ一週間)」という記事の続編です。その記事では、私が5日間集中的に機械学習を学び、のめり込んでいった経緯について説明しています。 機械学習に挑んだ一週間 一般の人にとって機械学習の分野に足を踏み入れるのは、無謀なことに思えるでしょう。medium.com 私は順調なスタートを切った後も、時間を見つけて勉強を続け、およそ一年後には、仕事で機械学習を活用した初プロジェクトを立ち上げることができました。そのプロジェクトでは、さまざまなタイプの機械学習や自然言語処理(NLP)の技術を駆使して、 Xeneta の 潜在顧客の特定 を行っています。 趣味でやっていたことが仕事になって、とても嬉しかったです。 同時に、仕事として機械学習を利用するのは博士号を持つ限られた人だけだ、という思い込みも払拭されました
「いつか勉強しよう」と人工知能/機械学習/ディープラーニング(Deep Learning)といったトピックの記事の見つけてはアーカイブしてきたものの、結局2015年は何一つやらずに終わってしまったので、とにかく一歩でも足を踏み出すべく、本質的な理解等はさておき、とにかく試してみるということをやってみました。 試したのは、TensorFlow、Chainer、Caffe といった機械学習およびディープラーニングの代表的なライブラリ/フレームワーク3種と、2015年に話題になったディープラーニングを利用したアプリケーション2種(DeepDream、chainer-gogh)。 (DeepDreamで試した結果画像) タイトルに半日と書きましたが、たとえばTensorFlowは環境構築だけなら10分もあれば終わるでしょうし、Chainerなんてコマンド一発なので5秒くらいです。Caffeは僕はハ
§1はじめに Deep Learningってどのくらい理論的に解明されているのか?ってやっぱり気になりますよね。 それに関して、次のQuoraのスレッドに非常に有益なコメントがあります。 When will we see a theoretical background and mathematical foundation for deep learning? - Quora How far along are we in the understanding of why deep learning works? - Quora 深層学習界の大御所であるYoshua Bengio、Yann LeCunの二人が 実際ディープラーニングの理論的理解ってどうなのよ?? って質問に直々にコメントしています。 LeCunのコメントの冒頭を少し引用しますと; That’s a very active
インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。 「ネットワークって難しい/よくわからない」 最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。 書式統一のため sudo を省略しています。ご容赦下さい。 コマンド編 ping ping です。疎通確認を行う時のコマンドです。 さすがに分かると聞こえてきそうですね。 例えば、192.168.1.1 というサーバに通信を確認したい場合はこうです。 $ ping 192.168.1.1 繋がる場合はこうなります。 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 d
Got something to say? Share your comments on this topic with other web professionals In: Articles By Mike West Published on September 11, 2006 Scope is one of the foundational aspects of the JavaScript language, and probably the one I’ve struggled with the most when building complex programs. I can’t count the number of times I’ve lost track of what the this keyword refers to after passing control
技術部モバイル基盤グループ新卒エンジニアの日高(@natan3)です。 去る11月17日、「Cookpad Tech Kitchen #4 〜Cookpad × MoneyForward〜」と題して、iOS エンジニア向けの技術交流イベントを行いました。 https://cookpad.connpass.com/event/43082/ このイベントでは、 iOS開発の中でも特に大規模アプリの品質を維持するための設計や、複数の言語圏や様々なパートナー企業に合わせたアプリの提供をテーマに、弊社のエンジニアから2つ、マネーフォワードさんから2つの発表がありました。 この記事では、その様子についてお伝えします。 iOSアプリケーションの海外展開 まず、海外事業部の西山(@yuseinishiyama)から、海外事業向けのiOSアプリケーションの開発フローについて紹介がありました。 How to
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
フィードバックを送信 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 SEO とは、「検索エンジン最適化(search engine optimization)」または「検索エンジン最適化業者(Search Engine Optimizer)」の頭文字です。SEO 業者を利用するかどうかは、サイトの改善や時間の節約につながる可能性がある一方で、サイトや運営者の信用が損なわれるおそれもある重大な決定です。SEO 業者を利用するメリットと、無責任な SEO 業者によってサイトが被害を受ける可能性について必ず検討してください。多くの SEO 業者や代理店、コンサルタントでは、ウェブサイトの管理者向けに次のような便利なサービスを提供しています。 サイトのコンテンツや構成の見直し ホスティング、リダイレクト、エラーページ、JavaScript の使用など、ウェブサイ
the netscape dorm. © 1994-1996 Jamie Zawinski <jwz@jwz.org> Here are some excerpts from my diary during the first few months of the existence of Netscape Communications (All Praise the Company), back when we were still called Mosaic. Back when there were only 20 or 30 of us, instead of however-many thousands of people there are today. Back before we had any middle managers. This is the time period
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム(16年の歴史があります)の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く