You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
iOS 12と新型iPhoneを取り巻く「Apple Pay」最新事情：鈴木淳也のモバイル決済業界地図（1/3 ページ） 2016年10月に日本にもApple Payが正式上陸してから2年が経過した。対応クレジットカードも増加した他、Apple Pay上陸に合わせるかのようにiD、QUICPay、Suicaといった非接触の電子マネーやクレジットカード系サービスに対応する小売店も増え、日々活用しているというユーザーは多いだろう。2014年に初めてApple Payが発表された際、Apple CEOのティム・クック氏は「日々の生活に欠かせない」ものと同サービスを表現した。それから4年が経過し、実際に人々の生活は変化したのだろうか？ この見解には賛否両論あると思うが、少なくともApple Payの登場は「モバイル決済」というジャンルに大きな変革を促し、Apple Pay自身もまた変化する市場の状
Linus Torvalds様、ユーザースペースの互換性を壊した開発者に強い態度をお示しになる
Linuxカーネル4.18から、userns mountに対して暗黙にSB_I_NODEVを設定するようになったために、既存のsystemdのnspawn実装が壊れた。 以下が問題のパッチだ。 https://github.com/torvalds/linux/commit/55956b59df336f6738da916dbb520b6e37df9fbd Linuxカーネルにおいては、ユーザースペースの挙動は変えないという強い下位互換保障がある。以前のバージョンのカーネルで動いていたユーザースペースのコードが新しいバージョンのカーネルで動かなくなった場合、それは理由が何であれ新しいバージョンのカーネルのバグであるとみなされる。たとえそれが、ドキュメント化していない明示的に保証されているわけではない昔のカーネルの暗黙の挙動であれ、その挙動に依存している既存のユーザースペースのコードがあるので
アプリケーションエンジニアの id:alpicola です。 このエントリは、はてなエンジニアアドベントカレンダー2018の24日目の記事です。昨日は id:miki_bene のIntelliJを使ってPerlアプリケーションの開発をするでした。 背景 横断検索のアーキテクチャ 閲覧可能範囲の実装 検索精度を高める工夫 形態素解析器Sudachiの使用 N-gramインデックスの併用 おわりに 背景 はてなでは業務の中で得た知見や考えたことなどを書き残し、社内外でどんどん共有していくオープンな文化があります。こうやって発信された情報はエンジニア同士で相互によいインプットになってきました。一方で、情報がそれを必要としている人に必ずしもアクセスしやすくないという課題も抱えています。 発信される情報の量が多く、少し時間が経った情報はすぐ流れてしまう 社内でグループウェア、GitHub Ente
「分からない」が将来を潰す 「インターネットってどうせ流行りでしょ？」 「FAXのほうが良いじゃないですか」 「今までのやり方で上手くいっているから必要ない」 小さな頃から web を当たり前のように使っていた人には信じられないですが、昔はそんなことを言っていた人がいました。企画提案をするにしても、過ぎ去っていく流行ではないことを説得するところからスタートすることもありました。 若い頃は昔の価値観にしがみついている人たちにどう伝えれば良いか分からなくて苦労しましたし、自分が『オジサン世代』になったら絶対こうなりたくないと思っていました。自分には分からないから、周りにはさせないみたいな態度が成長を遅れせてしまうのではないでしょうか。 『オジサン世代』になってしまった今でもそう考えながら仕事していますが、周りが次第に閉鎖的になっているのを見ると「ヤバいな」と感じることがあります。 「TikTo
2016-2017年でのNIST SP800-63-3改定を通じて、認証を含むデジタルアイデンティティの世界では様々な議論が湧き起こりました。 そんな本ガイドラインの内容を通じて、デジタルアイデンティティフレームワークを考える上での共通言語、特に「認証方法」について記載したNIST SP800-6…
gitのworkspace内がcleanかどうか確認してからコマンドを使いたいことがあった。そこで変更があるかをgitでチェックする方法について調べたのでメモ。 結論としては以下のようにすると良い。 if [ -z "$(git status --porcelain)" ]; then # Working directory clean else # Uncommitted changes fi perlとかだとこんな感じ。 if (`git status --porcelain`) { warn 'dirty'; } else { warn 'clean'; } ちなみにgit diff --exit-codeという方法でも行けそうだったので試してみていたのだけど、こちらはファイルの変更は検知できたけど、ファイルの追加(Untracked files)は検知できなかったので、うまくいかな
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
