みなさんはコーディング規約を利用していますか。 個人で開発している時はオレオレルールで良かったのですが、 複数人で開発するようになると共通のルールがあった方がストレス無く開発が出来るようになります。 WEB系の言語のコーディング規約について、調べ物が必要だったので、 まとめたものをブログでもシェアします。 HTML・CSS Google HTML/CSS Style Guide の推奨ガイドラインまとめ HTML5 コーディングガイドライン(HTML5)ver1.0 JavaScript JavaScriptのいろいろなコーディングルールをまとめてみた PHP PHPのコーディング規約 PSR-0、PSR-1、PSR-2、PSR-3とは WordPress コーディング基準 Pear Manual :: 標準コーディング規約 Zend Framework PHP 標準コーディング規約 Ca
リモートワーク ハンドブック #このサイトについて #NTTコミュニケーションズ社内で製作したリモートワークハンドブックの内容を、 より一般化して広く公開するものです。 ソースコード #本書のソースコードは https://github.com/nttcom/remote-work-handbook で公開しています。 ライセンス #NTT Communications Corporation 作『リモートワーク ハンドブック』は クリエイティブ・コモンズ 表示 - 非営利 - 継承 4.0 国際 ライセンス で提供されています。 関連ハンドブック #オンボーディングに特化した オンボーディング ハンドブック や、チームビルディングのプラクティスをまとめたチームビルディングハンドブックも参照ください。 読み始める #こちらから本編に進めます。 本書について
3streamer.net 2024 著作権. 不許複製 プライバシーポリシー
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
エンジニアが知っておくべきデザインの基本。「デザインガイドライン」と「コンポーネント」を学ぶ! Appleをはじめとする多くの成功企業がデザイナを役員に据えるなど、デザインに対する重要度が年々上がっているこの時代、若手のうちにUIデザインに関する基本的な考えを身につけ、より良いプロダクトを制作できるエンジニアを目指しましょう。 こんにちは。 グロースデザイナ/フロントエンジニアとしてWebサービス開発に携わっている右寺(@migi)と申します。最近は複数の企業で、数値解析から企画提案、開発も含めてサービスを成長させるためのお手伝いをしています。 現在はフリーランスとして活動していますが、直近では株式会社グッドパッチというUI(ユーザインターフェイス)デザインに特化した会社に勤めており、そこではデザインとの距離がとても近いところで開発をしていました。 そんな私の経験から、この記事では「エンジ
フィードバックを送信 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 検索エンジン最適化(SEO)スターター ガイド ウェブサイトの構築時には、ユーザーを念頭に置き、見つけやすく閲覧しやすいサイトになるよう工夫するのが普通です。検索エンジンもユーザーの一種ですが、コンテンツを見つけるためにユーザーの手助けをします。SEO(検索エンジン最適化)では、検索エンジンにコンテンツを理解させることで、ユーザーが検索エンジンからサイトを見つけてアクセスすべきかどうかを判断できるようにします。 検索の基本事項では、ウェブサイトが Google 検索の表示対象となるために特に重要となる事項を説明しています。Google のインデックスに確実に登録される方法はありませんが、検索の基本事項に沿って作成したサイトは Google の検索結果に表示されやすくなります。SEO とは
ようこそ 時代遅れの情報がウェブ上にあふれている。そんな情報を見たPHP初心者は戸惑ってしまうだろう。そして、まずい手法やまずいコードが広まってしまう。 そんなのはもうやめよう。PHP: The Right Way は気軽に読めるクイックリファレンスだ。PHPの一般的なコーディング規約、 ウェブ上のよくできたチュートリアルへのリンク、そして現時点でのベストプラクティスだと執筆者が考えていることをまとめた。 大事なのは、 PHPを使うための正式なお作法など存在しない ってこと。 このサイトの狙いは、はじめて PHP を使うことになった開発者に、いろんなトピックを紹介すること。 経験豊富なプロの人にとっても、これまで深く考えることなく使ってきた内容について、新鮮な見方を伝えられるだろう。 このサイトは、決して「どのツールを使えばいいのか」を教えるものじゃない。 いくつかの選択肢を示して、それぞ
ローソンは2020年春、プライベートブランド商品のロゴ・パッケージを刷新した。これまでの「ローソンセレクト」を「L basic(エル ベーシック)」「L marche(エル マルシェ)」の2つのブランドに一新したという。手掛けたのは国内外で幅広いクリエイティブを行うデザインオフィスnendoだ。 確かにデザインは美しい。しかし店頭に並んだ商品を見ると、統一感はあるが何の商品だかわかりづらい。Twitterでも「前のデザインの方がわかりやすかった」という消費者の声が目立つ。 筆者の和久井は、ライターと並行して合同会社ブラインドライターズという、視覚障害者を中心とした会社を運営している。スタッフには、中心視野が欠けていて焦点が合わない人、全体的にぼやけて見える人、トイレットペーパーの芯から物を覗いているように見える視野の狭い人など、さまざまな視覚の状態の人がいる。彼らにも見てもらったが、「非常
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
Perl › here Perl5.8以降における標準的なPerlの書き方を解説します。 インターネットで検索するとPerl4のころの古い記述がたくさんあります。また書籍などの多くもPerl4の記法で書かれています。Perl4の記法は複雑になりやすく間違いを生みやすいのでこれからPerlを書く人はPerl5の現代的な記法で記述することを強くお勧めします。 strictプラグマとwarningsプラグマ (必須) strictプラグマとwarningsプラグマを有効にします。 use strict; use warnings; use strict;とuse warnings;の2行はスクリプトの最初に必ず記述してください。これらはPerlの文法チェックを厳しくするためのものです。面倒だという軽い気持ちでこれを記述しないと後々本当に面倒なことになります。 use strict;とuse wa
Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started |
howto-tech-docs.md 技術文書の書き方 このメモは、私(@ymmt2005)が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
スマートフォン向けの Web サイトを作るとき、viewport の設定次第で使い勝手が大幅に変わる。 最近はレスポンシブ Web デザインが流行してるけども、その大前提として viewport の設定パターンを抑えておくのは重要だろう。 この記事では、viewport の設定によって、見た目・使い勝手がどう変わるかを解説する。 パターン1: 何も考えずに HTML を書く まずは、viewport を指定せずに、単純な HTML をスマートフォンで表示してみる。 <!DOCTYPE html> <head> <meta charset="utf-8"> </head> <body> <img src="/images/logo-ja.png"> <p>色んな素材がごった煮になった様子をお椀で表現しています。 湯気が<strong>「てっく」</strong>に見えるのが隠し味になっていま
ヤコブ・ニールセンの考えをまとめたユーザビリティガイドライン ユーザビリティのグル、ヤコブ・ニールセン氏の考えや調査を元にユーザビリティガイドラインを作りました。 デザインやコーディングをしている際に、このガイドラインを元に自分のデザインを一度チェックしてみるのもよいかと思います。 TRANS - ヤコブ・ニールセン氏の考えを元に、ユーザビリティガイドラインを作った。
任天堂は当社が創造するゲームやキャラクター、世界観に対して、お客様が真摯に情熱をもって向かい合っていただけることに感謝し、その体験が広く共有されることを応援したいと考えております。 任天堂は、個人であるお客様が、任天堂が著作権を有するゲームからキャプチャーした映像およびスクリーンショット(以下「任天堂のゲーム著作物」といいます)を利用した動画や静止画等を、適切な動画や静止画の共有サイトに投稿(実況を含む)することおよび別途指定するシステムにより収益化することに対して、著作権侵害を主張いたしません。ただし、その投稿に際しては、このガイドラインに従っていただく必要があります。あらかじめご了承ください。 個人であるお客様は、任天堂のゲーム著作物を利用した動画や静止画等を、営利を目的としない場合に限り、投稿することができます。ただし、別途指定するシステムによるときは、投稿を収益化することができます
JavaScriptは移り変わりの早い言語です。 もう1年以上経っていますし、記事のメンテもちゃんとできていないので、消し線を入れることにしました。 参考程度のために記事は一応残しますが、より新しい情報を読まれることをお勧めいたします。 はじめに --- 最近では JavaScript の実行環境はブラウザに限りません。(node.js, Web Workers) また、旧来のような <script> 経由でのロードもとうに古くなっています。今は CommonJS スタイルで、require を用いたモジュールのロードを行なうことがより良いとされています。 ですから、次のようなことは改める必要があります。 - var YourModule = {}; などとして、外部から YourModule.hoge(); などと呼び出す書き方 - this === window だと思うこと 今回は、
iPhoneとAndroidではiPhoneのほうが良くできているが、iOSのフラットデザインとAndroidのマテリアルデザインでは後者の設計が優れている。マテリアルデザインは、デザインとエンジニアリングが高いレベルで融合していて、ロジカルで非常に美しい。 以下、自分の理解をまとめたメモ。 紙とインク マテリアルデザインは「ペーパー」と「インク」のメタファーでできている。 ペーパーの特徴 バーやボタンといった画面上のUIコンポーネントは、バーチャルな紙でできたカードと考える。また、このペーパーは1dpの厚さを持っている。 ペーパーは純白の矩形、あるいはシンプルな円形である。三角や星型といった複雑な形はとらない。そのような複雑な形状や模様はインクが担当する。 現実とことなり、このペーパーは自由に伸縮することができる。 マテリアルデザインにおけるレイアウトは、複数のペーパーを並べたり、重ねた
※2019年12月22日 0:50追記 cheeroの東さんからご連絡を頂き、ネタフル及びその他ブロガーの方々の記事中に、cheeroとの関係性について明示されないまま紹介記事が書かれていたケースについて改めて謝罪がありました。 cheeroからはブロガーの方々に対し「cheeroから提供された商品を使用し、記事を作成する場合は『提供』もしくは『PR』といった文言を記載する事を求めていた」との事ですが、記載が徹底されていない事については社内で早急に検証の上改めて対策を練ると共に、今回の経緯と対策について後日リリースを出す方針だそうです。 なお、それを受けて僕としては「もうこの辺でいいかな」という気持ちがあるので、cheeroについてステマ呼ばわりした僕のツイート、及び今回の記事の該当部分は様子を見た上(たぶん12月22日の夜くらい)で修正なり削除なりの対応を行いたいと思います。お騒がせして
9月1日、BuzzFeedで「Abemaが非公開にした『くそババア』罵倒映像 過激化するネットテレビの2つの問題」という記事が配信されました。拝見したところ、結構なバズり具合です。 冒頭に出てくる、「生放送中に男性陣からハラスメントにあった」とBuzzFeed Newsに連絡したAさんとは私のことです。記事は「規制のないネットテレビの問題点」を洗い出し、社会に問う内容ですが、ここでは私自身が気持ちに整理をつけるためにも、事の次第を振り返ってみたいと思います。 noteというメディアを使うのは初めてなので、不慣れゆえ至らないところも多いでしょうが、どうかご容赦ください。 *以下、お酒の席でハラスメント、暴行、虐待を受けた経験がある方、目上の人から大声で罵倒された経験がある方には読んでいてつらい記述もあると思います。ご注意ください。 はじめまして、の方も多いと思うので最初に簡単な自己紹介をいた
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
2012年7月12日のGoogle ウェブマスター向け公式ブログの記事「HTML と CSS のコーディングガイドライン」で紹介されていた「Google HTML/CSS Style Guide」に書いてあるコーディング方法と感想を紹介します。 Google HTML/CSS Style Guideの日本語翻訳 Google HTML/CSS Style Guideは英語なのでGoogle Chromeで翻訳して確認していたんですが、すでに翻訳してあるサイトがあったのでこちらも参考に両方を見て確認していきました。 Google HTML/CSS Style Guideを翻訳してある記事「Google HTML/CSS Style Guide」を適当に和訳してみたは、かなり助かり参考になりました。 それではGoogle HTML/CSS Style Guideに書いてあるHTMLとCSSのコ
2021/9/23プロジェクトリードにおける考察について取り入れた2021/10/11職種の人数が多い、アプリケーションエンジニアを対象として、まずは内容を詳細化してアップデート2021/12/10プロフェッショナルの年収を520~550万を520~570万に変更チーフプロフェッショナルの年収を550~600万を570~620万に変更マルチリードエンジニア、チーフテックリード、リード・アーキテクト、チーフマイスターエンジニアの年収上限を950万から1000万に変更アーキテクト、リードアーキテクトの職位ガイドラインの詳細(暫定)を追加2022/4/11リードエンジニアの年収レンジを650-700万についてを、650-720万に変更チーフリードエンジニアの年収レンジを超える700-800万から、720-800万に変更2023/3/13 プロフェッショナルのチームコラボレーション(主体性)に追加
お客様各位 日頃よりサウンドハウスをご利用頂き誠にありがとうございます。 突然ですがこのたびサウンドハウスは楽天への出店をとりやめることと致しました。 サウンドハウスはこれまで3年間、楽天市場に商品を掲載しておりました。ところがこの度、楽天は一方的に弊社の決済口座としては楽天銀行の口座に一本化するということを決め、お客様に告知しました。出店店舗の銀行口座を勝手に開設し、決済用口座としてはその口座しか認めないということは、これまでの日本の商習慣ではありえないことです。 この事態に対して、楽天には詳細説明、及び即時撤回を申し入れましたが、納得できる説明もなく、口座の取り消しも実行しないことが判明したため、弊社ではやむを得ず、楽天との取引を中止することと致しました。国内トップのインターネット事業を営む楽天が、自社グループの利益のみを追い求め、出店している店舗に対して一方的にこのような暴挙を行うこ
最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整
2020.08.27 スキル 2020年4月21日、NTT東日本と独立行政法人情報処理推進機構(以下、IPA)は、新型コロナウイルスの流行によって在宅勤務を強いられている人々を支援するため、無償かつユーザー登録不要で利用できるシンクライアント型VPN『シン・テレワークシステム』の提供を開始した。 このシステムを構想からわずか2週間あまりでリリースに漕ぎ着けた中心人物こそ、今回紹介する登大遊さんだ。 登 大遊(のぼり・だいゆう)さん 1984年兵庫県生まれ。2003年に筑波大学に入学。同年、IPA(独立行政法人情報処理推進機構)の「未踏ソフトウェア創造事業 未踏ユース部門」に採択、開発した『SoftEther』で天才プログラマー/スーパークリエータ認定を受ける。17年、筑波大学大学院システム情報工学研究科博士後期課程修了。博士 (工学)。現在、IPAサイバー技術研究室長のほか、ソフトイーサ株
フェイスブック楽しい! はじめに みなさんこんにちは!フェイスブックしてますか? ゆうすけべーが書いているように、最近本当にフェイスブックがおもしろいなーと感じます。 ゆーすけべー日記 というわけで、一人で使っていたときから人が増えてきたときまでの雰囲気を思い出しつつ、僕が感じているフェイスブックのおもしろさ、特徴、楽しみ方などを紹介していけたらと思います。 ちょっと長くなっちゃいますけど、よろしくお願いします! フェイスブックの一番の面白さは「速さ」 僕が感じているフェイスブックの良さは、一言で言ってしまえば「コミュニケーションの速さ」なんだと思います。 速さと言っても、システム的な速さだけではなくって「コミュニケーション」の速さです。 フェイスブックの「コミュニケーションの速さ」は主に以下の3点にあると思っています。 「左下」の通知が素早い 書き込むより早く「いいね!」が伝わる 「一緒
とあるコンサルタントのつぶやき とあるコンサルタントのつぶやき MCS (Microsoft Consulting Services) の某コンサルタントがまったり語るテクノロジのお話です。 ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが;、二回分のエントリを通して読めば、牛尾さんが言いたい
(訳注:2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注:著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例: 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く