「マージがなんとなく怖い」「リベースするなって怒られて怖い」「エラーが出て怖い」 Git 入門者にありがちな「Git 怖い」を解消するため、Git のお仕事(コミット、ブランチ、マージ、リベース)について解説します。
![Dockerイメージ管理の内部構造](https://cdn-ak-scissors.b.st-hatena.com/image/square/056c4282659924a442581d8181ef23f9d79e5af6/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fdockerimageinternalv10-150127224053-conversion-gate02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
パスワード管理アプリの1Passwordがもう一歩進んだ便利さを提供してくれるようになりました。 1Passwordがどのようなアプリかというのをさらっと復習しておくと、 ・IDやパスワードを管理できる ・パスワードを生成してくれる ・ブラウザなどのExtensionから呼び出すことでIDとパスワードを自動入力してくれる ・TouchIDを使い指紋認証だけで呼び出せる 管理とログインを容易にしてくれるって感じですね。 今回それに2段階認証の対応が加わりました。これはPro版の新機能です。 1Password 無料 販売: AgileBits Inc. 評価: 4(657件) iPhone/iPadに対応 Pro版にするにはアプリ内科金1,000円が必要です。 2段階認証とは パスワード流出事件は後を絶ちません。 ユーザーがどんなに気を付けていても、流出してしまったら悪用されてないことを祈る
遂に、師走となりました。1 年を振り返る時期がやってきましたね!年末は、その年の出来事を追想する時です。私たちのチームでは、各メンバーが次のようなことを考えます。 上手くいったことは何か? 自分は、何を達成したか? 自分のどのような点を更に改善していきたいか? 今年できなかったことで、来年やりたいことは何か? そう、12 月は 1 年の出来事を追想する ふりかえり (これが、カッコいいアジャイルの言い方です) の時期です。 ふりかえり とは、スプリント、イテレーション、あるいはリリース後に行われるミーティングを指します。これによって、アジャイルチームが学習・成長して、製品文化と開発文化をより一層向上させる機会を得られます。また、成功点と再発する問題点に焦点をあてることで、チームがプロセスを継続的に向上できるようになります。私たちは、チームの ふりかえり にかける時間を、大体 1 時間に設定
AWS の public DNS に対して ansible を実行すると、us-east-1リージョンでは成功するのに、ap-southeast-1リージョンでは、ControlPath too long というエラーが発生するという現象に悩んでいた。 よくよく調べてみると、デフォルトが %(directory)s/ansible-ssh-%%h-%%p-%%r という設定になっていて、ap-southeast-1リージョン(*.ap-southeast-1.compute.amazonaws.com)のように長いホスト名だと108文字の限界を越えてしまうせいだった。 The path to use for the ControlPath sockets. This defaults to "%(directory)s/ansible-ssh-%%h-%%p-%%r", however o
Grailsのドメインクラスにおいて、いくつかの候補の数値のいずれか、というフィールドを作成し、scaffoldで生成した画面からCRUD操作したいとします。 簡単なのは、こうですね。 class Domain { Integer something static constraints = { something inList:[1,2,3] } } しかし数値フィールドに量としてではなく個々の値にそれぞれの意味がある場合、たとえば、腹の状態を表すフィールドの値として、 1: はらぺこ 2:まんぷく 3:こばらがへった を表現するようなものだったとします。このとき、すくなくとも、Scaffoldの画面上では数値ではなく意味のわかる文字列で表示したり選択入力させたいわけです。しかしデータそのものを文字列にするのもDB上の表現をそうしたくないのでいやだとします*1。 ということでenumの出
今、Node.jsに起きてることを語る上で、io.jsは避けて通れない話題でしょう。 今回のNode.js アドベントカレンダー 2014の締めを飾るために、このio.jsについて僕が知っている限りの事をまとめて書くことにします。 io.jsを知り、今後"Node"がどうなっていくのかを皆で一緒に考えていきましょう。 またこの一連のio.jsのfork騒動はOSSという特殊なプロジェクトをどう進めていくのがハッピーなのかを知る一つの教材だと思います。 OSSに関わっている皆さん、今回も長いですが、最後まで読んでもらえると幸いです。 io.js とは何か Node.jsのForkです。次のNode.jsの安定版になる、v0.12をForkしています。「アイ・オー ジェイエス」と読みます。名前の由来は木星にある四番目に大きな衛星の名前から取られました。*1 Nodeを使っている人のことをnod
こんにちは、せーのです。 去年の11月にアメリカ・ラスベガスにてre:Invent2014が開かれ、AWSの新しいサービスが次々と発表になりました。クラメソからも数名有志がラスベガス現地に乗り込み、発表会場その場でひたすらブログを書き続けるという新サービス無双を、日本待機組は紹介されたサービスを日本でひたすらやってみる、というやってみた無双を展開致しました。「クラスメソッドの方はブログ以外にいつ仕事をしてるんですか?」と言われる本領が発揮された素晴らしいイベントだったと思います。詳しくはこちらにまとめられておりますので御覧ください。 AWS re:Invent 2014 – シリーズ – AWS re:Invent2014【保存版】全セッションを網羅!非公式まとめ 今日はこのre:Inventをより楽しめるお話です。 実は話してる英語がぼんやりしかわからなかった re:Inventにかぎら
こんにちは、せーのです。明日から仕事、という方も多いのではないでしょうか。徐々に頭を通常モードに切り替えていきましょう。 さて、今日ご紹介するのはごくごく個人的な備忘録です。あと最近クラメソに入社した、という方もちらほら出てきているのでその方々向けの情報提供でもあります。AWSのリリース情報やアップデート情報のチェック方法についてまとめてみました。 ただ情報はどうしても英語になってしまいます。ですので日本語で詳しく知りたいんだ、という方はここ、developers.ioをチェックしてください。全記事読んでいる、という強者の方は是非右上からエントリーを。 何語でもいいからとにかく1秒でも早く最新情報が知りたい、という方はこれから書くURLをチェックしておくと、大体の最新情報が手に入るかと思います。 基本はリリースノート ここは外せません。サービスのアップデート情報等はここに載るのでまずここを
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
メソッド名などをネーミングする際に、知っておくと便利な、接頭辞と接尾辞をリストアップしてみました。どのように元の単語の意味が変わるかのルールを知っておくと、よく使う単語をベースにボキャブラリーを増やすことができるので、覚えておいて損はないと思います。 使う場合は、当たりを付けて実際の使用がないか、Googleなどで調べてみてください。 1. pre-, post- / 事前〜、事後〜 per-は、元の意味に “事前に、前に”、post-は “事後に”という意味が付け加わえます。汎用性が高いのでとても便利です。afterやbeforeの代替になるかもしれません。 // 事前テストする function testBefore(); ↓ function pretest(); // 事後処理する function executeAfter(); ↓ function postexecute();
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
以前、 OpenVz コンテナだった私の” ホームクラウド “と、 私があらゆるビルドに関して”ビルドサーバ”のリビルドを推奨するようになったワケ について書きました。 Docker はあっという間に私のお気に入りのツールに仲間入りしました。限りなく静的なサーバ環境を作り出す繰り返し可能なビルドを作成するという考え方が気に入ったからです。 今回は、私がDockerを使用する中で繰り返し現れるようになったいくつかのパターンを説明します。どれも特段に目新しいものでも非常に驚くようなことでもありませんが、皆さんにとってそれが役立つものであり、また皆さんがDockerを使用する中で遭遇するパターンについても聞くことができれば幸いです。 私がDockerを使って色々なことを試す根本にあるのは、データを喪失することなくDockerコンテナそのものが自由に再作成できるよう、ボリュームにあり続ける状態を維
Sometimes developers don’t implement the Test Driven Development (TDD) methodology just because the project they are building is small and does not need testing frameworks. But, this is a fatal… Routing in web applications allows for seamless navigation, ensuring users effortlessly access different pages and resources within an application. As such, when implemented correctly, routing offers an in
Dockerレジストリ は、今やあふれんばかりの状況です。これを書いている時点で、”node”と検索すれば、1000件弱の結果がヒットします。どうやって選べばいいのでしょうか? いいDockerイメージを構成するもの いい悪いは主観ではありますが、私がいいと考えるDockerイメージには、いくつかの基準があります。 実用的: 以下に例を挙げます。 最初にコンテナにアップデートを適用しなくても、Android SDKのイメージがプロジェクトをコンパイルできる。 MySQLのコンテナが、データベースとユーザを使用してサーバをブートする方法を明示する。 最小限: コンテナの利点は、アプリケーションをサンドボックスできること(セキュリティがない場合には、ホストファイルシステム上で混乱を避けられること)です。ホストシステムにnode.jsをインストールしたり、JDK(Java開発キット)でシステムを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く