Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き
現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、
機械学習をプロダクトに入れる際に考える採用基準について - yasuhisa's blog
サービスに機械学習技術(例えばSVM)を入れる際に、「この機械学習技術は本番サービスに投入しても大丈夫なものか?」を考える基準がまとまっていると人に説明するときに便利だなとふと思ったのでまとめてみました。散々言われ尽くされている話だとは思います。 前提 考慮に入る採用基準 予測精度 (コードの)メンテナンスの容易性 計算オーダー 学習時 予測時 挙動のコントロールのしやすさ/予測説明性の容易さ チューニングの必要性 その他 まとめ 前提 機械学習がプロダクトの主要な武器になる(例えば最近話題になっているGoogle翻訳におけるNMT)ものではなく、サービスにデータがまずあり、機械学習でデータを活用することにより、そのサービスを支えていくようなものを前提に考えています(例えばCGMサービスのスパム判定)。また、投稿内容は私個人の意見であり、所属組織を代表するものではありませんとお断りしておき
iOS ヒューマンインターフェースの原則 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴からデザインの原則、それぞれの部品が何のためにデザインされたのか、どう利用するのか、iOS を構成する UI の基本指針がまとまっています。 よく、『磨りガラス効果がかっこいい』『アニメーションしておくとイケてる』『ボタンは右配置の方が右手で押しやすい』『流行っているから』……などの観点によって UI の設計が
非公開だった検索品質評価ガイドラインの最新版をGoogleが公開
[レベル: 中級] 検索結果の品質を評価するためのガイドラインの最新版をGoogleは公開しました。 これまでのものとは変更がない部分がある一方で、新たにモバイルに関する章が加わったことが最新版の最大の特徴となっています。 検索品質評価ガイドラインとは？ Googleは、ユーザーのクエリに対して関連性が高くかつ高品質なページを検索結果で返すことができているかどうかを、外部の評価者（Evaluator）に常に評価させています（評価者は普通に求人として募集されているらしい。日本でさえも）。 評価者による評価は検索品質の改善のために役立てられます。 直接的にランキングを調整するためには用いられません。 どのように検索結果の品質を評価するかを説明した「General Guidelines」（一般ガイドライン）というマニュアルが評価者に提供されます。 このマニュアルは原則的に評価者だけに配布されます
ジュンク堂「非公式アカウント騒動」が「言論問題」にすり替えられてしまった理由
スピン経済の歩き方： 日本ではあまり馴染みがないが、海外では政治家や企業が自分に有利な情報操作を行うことを「スピンコントロール」と呼ぶ。企業戦略には実はこの「スピン」という視点が欠かすことができない。 「情報操作」というと日本ではネガティブなイメージが強いが、ビジネスにおいて自社の商品やサービスの優位性を顧客や社会に伝えるのは当然だ。裏を返せばヒットしている商品や成功している企業は「スピン」がうまく機能をしている、と言えるのかもしれない。 そこで、本連載では私たちが普段何気なく接している経済情報、企業のプロモーション、PRにいったいどのような狙いがあり、緻密な戦略があるのかという「スピン」を紐解いていきたい。 読んでいただければ分かると思うが、「従業員による私的なTwitterアカウントより、特定の意見を支持するツイート」があったけれど、これは会社の公式な意思・見解とは異なるという「釈明」
PHPのJSON HashDosに関する注意喚起
4年前にHashDos（Hash Collision Attack）に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね？ json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
ひらがなで書くべき漢字のまとめ: 企業サイトで使用する「ひらく漢字」「ひらかない漢字」
これまでに数多くの一部上場企業様のWebサイトのリニューアル・サイト制作にコアメンバーとして参加し、その中で表記ルールもかなりの数を策定してきました。策定時のベースに使用する「ひらく漢字」「ひらかない漢字」の一部を紹介します。 ※以前、公開した記事を再編集したものです。 表記ルール: ひらくことが多い漢字 表記ルール: ひらくことを検討する漢字 表記ルールの策定にあたり 表記ルール: ひらくことが多い漢字 ひら（がなで書）くことが多い漢字。 ※「正・誤」は使用する際の基準であり、日本語としての「正・誤」ではありません。 読み 正 誤
JavaScript と altJS - ペパボのフロントエンドスタンダード
TypeScript について (1) 利用するメリット Java や C# のような文法の altJS です。下記に当てはまる場合は有力な選択肢です。 既存プロジェクトを altJS に移行したいとき JavaScript の文法そのままコピーして使用できるため 静的型付けをしたいとき 現状 TypeScript 一択です 新規の中・長期に渡る大規模プロジェクトのとき 静的型付やインターフェースを利用できるため (2) 利用上の注意 ただし TypeScript を利用する上で注意する点もあります。 コンパイルが遅い 型チェック等があるため、altJS の中でも特に遅めです this の用法が増える クラスのメンバ変数の参照には this.foo と記述します (3) サンプルコード // sample.ts module Saying { export class Greeter {
安全なウェブサイトの作り方改訂第7版の変更点と変わらない点
IPAの安全なウェブサイトの作り方 改訂第7版が公開されました。 このエントリでは、安全なウェブサイトの作り方の元々もつ特徴（変わらない点）と、第7版の変更のポイントについて説明します。 なお、私は安全なウェブサイトの作り方の執筆者の一人ではありますが、以下の記述は私個人の意見であり、IPAを代表するものではありませんので、あらかじめご承知おきください。 安全なウェブサイトの作り方の変わらぬ特徴 安全なウェブサイトの作り方の特徴は、「まえがき」の中で述べられています。 本書は、IPAが届出を受けたソフトウェア製品およびウェブアプリケーションの脆弱性関連情報に基づいて、特にウェブサイトやウェブアプリケーションについて、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、その根本的な解決策と、保険的な対策を示しています。 すなわち、以下の2点がポイントと考えます。 脆弱性の選定
Git を学ぶ - チュートリアル、ワークフローおよびコマンド | Atlassian
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVS といった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。これは、最初のリポジトリのクローン作成に時間がかかりますが、commit、blame、diff、merge、log といったこれに続く作業を劇的にスピードアップします。 Git は多くの革新的で強力なワークフローやツールにつながる、リポジトリ履歴のブランチ、マージ、および書き換えに非常に役立ちます。プル リクエストは、チームが Git ブランチでコラボレーションを行い、他のコードを効果的に見直すことができる、非常に人気のツールです。Git は現在世界で最も広く使用されているバージョン コント
CSSを書く時、絶対に参考にしておきたいCSSガイドラインのまとめ
CSSはどちらかと言えばやさしく、雑にコードを書いてもなんとかなってしまう言語です。 しかし、雑にコードを書いてしまうと、昨日書いたこのコードなんだっけ？ とか、新しくスタイルを増やすと別のスタイルがおかしくなってしまうことはありませんか？ 大規模なプロジェクト、長期に渡るプロジェクト、複数のメンバーが関わるプロジェクト、そして明日の自分も一年後の自分も使える、メンテナンス性に優れた一覧性のある美しいCSSを書くのに役立つガイドラインを紹介します。 CSS Guidelines 2 CSS WizardryのHigh-level guidelinesの最新版（2014年8月リリース）。 大規模で長期に渡るプロジェクト向けのメンテナンス性に重点をおいたスタイルシートのガイドラインです。スキルの異なる制作者、新規で加わる制作者などでも、統一されたコードでの制作が可能になるのを目的としています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインの勉強にいい！有名ブランドのガイドラインのまとめ