タグ

2018年7月2日のブックマーク (18件)

  • スルガ銀、オーナーを「詐欺師」と非難 訴訟で対決姿勢:朝日新聞デジタル

    スルガ銀行(静岡県沼津市)の中古1棟マンション投資向け融資で資料が改ざんされた問題で、融資を受けた岡山県の30代男性が不動産業者やスルガ銀などに計約2億3千万円の損害賠償を求めた訴訟の第1回口頭弁論が2日、大阪地裁であった。原告側は、男性の年収が足りないのに資料改ざんで融資され、割高な物件を買わされたと主張したが、スルガ銀は「(原告男性が)虚偽事実を告げて来なら融資できない金額の融資を詐取した」などと主張し、請求棄却を求めて徹底的に争う姿勢を示した。 訴えられたのは大阪市の不動産販売業者と勧誘業者、スルガ銀と同行京都支店の融資担当者。融資資料の改ざん問題で、スルガ銀に対して損害賠償を求める訴訟は初とみられる。 訴状によると、男性は2015年9月、投資目的で中古マンション1棟と新築マンション2室を計約2億3千万円で購入。全額をスルガ銀で借りたが、融資過程で通帳コピーや確定申告書などが改ざん

    スルガ銀、オーナーを「詐欺師」と非難 訴訟で対決姿勢:朝日新聞デジタル
  • OSSが検定ビジネス勢によって #商標ハック を受けた場合の対処法 – Capital P – WordPressメディア

    稿は2018年7月2日に公開された記事「『日ワードプレス協会』に感じるモヤモヤと検定ビジネスについて」をリライトしたものである。Pythonの商標ハックを受けて、より汎用的な内容になるよう追記を行なった。 OSSは社会的な資産である。伽藍とバザールの例を引くまでもなく、OSSによって人は自由に活動を行うことができる。インターネットにおける基的人権といってもよいOSSであるが、善意で支えられているがゆえに、クラックされてしまう。悪貨は良貨を駆逐するというわけだ。筆者がコントリビュートを行うWordPressもこうした脅威にさらされたがなんとか乗り切ってきた。稿ではそのノウハウを共有する。 商標を取ってしまう OSSには必ず国があり、当国ではその国の法律にのっとって商標保護が行われることが普通だ。商標というのはそれほど高価なものではなく、たとえば100人のユーザーがいれば1人500円

    OSSが検定ビジネス勢によって #商標ハック を受けた場合の対処法 – Capital P – WordPressメディア
  • The #2 most important idea in Computer Science

  • 転職エントリ - くりにっき

    from : 株式会社ドリコム (2012年7月~2018年6月) *1 to : ピクシブ株式会社 (2018年7月~) タイトルで煽らない、かしこまった見出しもつけない、ウィッシュリストのせない、東亜飯店張らない、fromとtoを両方書く。職場崩壊を暴露しない。キラキラしない。これが私の求める退職エントリです。— laiso🇯🇵 (@laiso) 2017年8月1日 こちらからは以上です。 *1:最終出社は5/25であとは1ヶ月間有給消化

    転職エントリ - くりにっき
  • ユーザーが許可したくなるPush通知を考える|sadakoa|note

    初めましての方もこんにちは、さだこえ (@sadako_a_ ) と申します。 DeNAに新卒で入社後、現在は株式会社FOLIOのデジタルプロダクトデザイナーとして、オンライン証券のUIデザインに従事しながら、スタートアップのデザイン支援を副業で行っています。 今記事では、主にアプリの機能として欠かせないPush通知に焦点を当て、記事を執筆します。 Push通知とはご存知の通りPush通知とは、アプリやwebサービスで何か変更や更新があった場合にお知らせをする機能です。一般的にこの業界で言われるPush通知は、Apple Push Notificationを指していることが多いと思われます。 その理由の1つとして、AndroidはPush通知に関してユーザーの許可を取る必要が無いからです。(ダウンロードする際にオプトインされるため、許可率は100%になる。) iOSやWeb Browser

    ユーザーが許可したくなるPush通知を考える|sadakoa|note
  • レンタルサーバのペナルティで強制的に「410 Gone」が返される事例に驚いた

    2017年5月 3日(水) 13時49分23秒 [Web関連] レンタルサーバのペナルティで強制的に「410 Gone」が返される事例に驚いた とある企業サイトに関して、「数ヶ月前からGoogleの検索結果に一切ヒットしなくなった」という相談を受けました。 いろいろ調べてみたところ、ウェブサーバにアクセスした際に返されるHTTPレスポンスヘッダが以下のような条件で分岐されていることに気付きました。 PCやモバイル端末で使われる一般的なブラウザのユーザエージェント名でアクセスすると、HTTPステータスコードには「200 OK」が返されていて普通に閲覧できる。 それ以外のユーザエージェント名でアクセスすると、HTTPステータスコードには「410 Gone」が返されて、一切閲覧できない。 なかなか謎の現象でした。 上記のようになっているので、Google Botなどが使っているユーザエージェント

    レンタルサーバのペナルティで強制的に「410 Gone」が返される事例に驚いた
  • いつもhiragramを応援してくださる皆様へ - hiragram no blog

    スタートトゥデイテクノロジーズ(旧VASILY)を退職します。今日から有給消化です。 次は決まっていません。8月からiOSらへんの技術者として雇ってもらえる会社を探しています。 最近業務やら個人やらでやったことは以下の通りです RxSwiftの啓蒙 ビットコインのアービトラージ取引支援アプリみたいなやつ OpenAPI(Swagger)ドキュメントからAPI定義/モデル型定義のコードを生成する仕組みの開発 任意の状態のスクリーンショットを収集する仕組みの開発 消費型課金/サブスクリプション型課金の実装 CI周りいろいろ API/UserDefaults/Keychainなどの抽象層の設計、実装 try! Swift Tokyo 2018で型安全なWebAPIモデリングについてLT発表 その他細々した発表 今の所あんまりやりたいと思っていないことは以下の通りです 医療 金融 新しい環境に強く

    いつもhiragramを応援してくださる皆様へ - hiragram no blog
  • Twitter での6年間 #7|Satoshi Nakagawa|note

    (Twitter での6年間 6 からの続き) Apple のイベントからしばらくすると、テックリードから提案があった。ぼくがデモ用に作ったライブラリの設計もコードもきれいで見通しがいいので、そのライブラリをアプリ体に組み込んで、既存のコードを置き換えてはどうかということだった。ぼくはその提案には反対だった。既存のコードによほど大きな設計ミスがない限り、同じ要求を与えれば同じコードができあがる。ぼくの知る限り、既存のコードに大きな設計ミスはなかった。ぼくは、まずゴールとなる新アーキテクチャーを設計し、既存のコードを徐々に置き換えていくことでゴールに近づけていくインクリメンタルアプローチを提案した。既存のプロモートツイート関連のロジックを新しいコードベースに意味もなく移植したりすることで問題を起こしたくなかったのだ。マネージャーや他のエンジニアたちも同意見で、新アーキテクチャプロジェクト

    Twitter での6年間 #7|Satoshi Nakagawa|note
  • Twitter での6年間 #6|Satoshi Nakagawa|note

    (Twitter での6年間 5 からの続き) 2014年3月、グリーンカード、つまり永住権の申請プロセスをはじめることにした。そのときぼくは H-1B ビザで働いていたのだが、このビザには6年の最終期限がある。2010年10月からなので期限まで残り2年半しかなかった。一度期限が切れてしまうと、基的には国外に出ていかなければいけなくなる。H-1B で働いていてこれからも US で働きたいと考える以上、グリーンカードを取得する必要があるわけだ。 6月の WWDC で、iOS 7 にシェアエクステンション機能が搭載されるとの発表があった。社内でそれを実装するために優秀なエンジニア2人のチームが結成された。この機能はアプリから独立した拡張として別プロセスで動作するので、iOS に標準搭載されている Twitter 連携機能を直接使う必要があった。そこでその問題について詳しいぼくが認証部分をチー

    Twitter での6年間 #6|Satoshi Nakagawa|note
  • Twitter での6年間 #5|Satoshi Nakagawa|note

    (Twitter での6年間 4 からの続き) 2013年の春ごろだっただろうか。上のほうの人が、A/B テストをプロダクト開発に活用することを推奨し始めた。A/B テストでプロダクトの方向性を決めていくというのだ。これにつられ、この頃の社内では A/B テスト万能論のような空気さえただよっていた。普通に考えて、A/B テストを数週間走らせてデータをとっても、それが長期的な成功につながるか判断できるはずがない。短期的に数字が上がるからといってユーザーの嫌がることを続けていれば、いつかユーザーの忍耐の限界に達してしまうかも知れない。そのユーザーの堪忍袋の状態をどうやって計測できるというのか、など疑問は尽きなかった。 そのころ Growth という大きな部署ができて、従来国際化を担当していた i18n エンジニアリングチームもその下に組み込まれることになった。Growth チームの強い権限のも

    Twitter での6年間 #5|Satoshi Nakagawa|note
  • Twitter での6年間 #5|Satoshi Nakagawa|note

    (Twitter での6年間 4 からの続き) そうこうしてるうちにコードネーム H という野心的なプロジェクトがスタートすることになった。最初は Hackweek の1プロジェクトとしてはじまったらしく、複数のタイムラインをスワイプで切り替えられるようにすることで、これまでのタブ UI による固定数のタイムラインではなく、たくさんのタイムラインをユーザーの好みに応じて追加することができるというアイデアだったらしい。このプロジェクトに iOS フレームワークチームのエンジニア全員が投入されることになった。当時 IPO の時期が近づいていたこともありクオリティよりも開発スピードを優先しないといけなかったので、まずレビューを一切なくして各自がコードをレポジトリに直接コミットすることになった。さらに、各機能のチームからの機能追加はメンテナンスブランチに対してのみ許され、しかも最小限に行うようにと

    Twitter での6年間 #5|Satoshi Nakagawa|note
  • Twitter での6年間 #4|Satoshi Nakagawa

    (Twitter での6年間 3 からの続き) 2013年に入り、iOS 6 の普及率も十分に高くなったころ、同僚のエンジニアから1つの提案がなされた。ツイートビューを作り直そうというのだ。その時点での Twitter for iOS は、iOS の黎明期に Apple が推奨していたように、できるだけビュー階層を減らして描画するようになっていた。たとえば、ツイートビューには一切サブビューがなく、ツイートテキスト、プロフィール画像、ユーザー名、タイムスタンプなどのパーツは直接ツイートビューに自前で描画する設計になっていた。当初はそのほうがパフォーマンス的に速かったからだ。それから数年間の Apple によるハードウェア、ソフトウェア両面での改善の結果、ベンチマークを取ってみるとどうやらその設計はもう古いらしいことがわかった。たとえば画像を表示するときに、自分でビューに CPU で描画するの

    Twitter での6年間 #4|Satoshi Nakagawa
  • React Nativeハイブリッドアプリへの挑戦 ~Part1: Monorepo/CI~ - スタディサプリ Product Team Blog

    エントリは3部作のPart1となっております。 Part1: Monorepo/CI Part2: 導入/Bridge Part3: 振り返り/今後 モバイルエンジニアの@hotchemiです。 数週間前にReact Native at Airbnb(非公式の日語訳)が世間を賑わせましたが、皆様いかがお過ごしでしょうか。 弊社でもここ数ヶ月Nativeで書かれたスタディサプリのiOS/AndroidアプリにReact Nativeを部分的に導入していく、いわゆるハイブリッドアプリ開発体制に挑戦しており、そこで得られた知見を何回かに分けて公開していければと思います。 Goals まず、なぜハイブリッドアプリという選択をしたのかについて、我々が目指していたゴールは以下の様なものです。 モバイルエンジニア不足の解消 Quipperは元々Webエンジニアの数が多い一方でモバイルエンジニアの人数

    React Nativeハイブリッドアプリへの挑戦 ~Part1: Monorepo/CI~ - スタディサプリ Product Team Blog
  • 退職しました - みんからきりまで

    6月末でAnyPay株式会社を退職しました。 AnyPayには正社員として1年、業務委託時代も入れると1年半お世話になりました。 なんでやめるの 簡単に言えば音楽性の違いみたいな感じです。 なにをやってたの AnyPayではAndroidエンジニアとして参加し、主にpaymoのアプリ開発をやっていました。 去年の2月に初めて出社した当時はまだAnyPayはとても小さな会社で、エンジニアの社員はCTOと社員代表の2人しかおらず、ぼくは初めてのフルタイムモバイルエンジニアでした。 そこからリモートや参加してくれている協力会社の方などと協力しながら、モバイルアプリの内製体制を少しずつ作っていきました。 アプリの設計見直し、テストコード、Kotlin導入 当時リリース直後でコードが若干無秩序だったpaymoアプリの設計見直しとKotlinの導入を行いました。 詳しくは以下のブログで解説しています。

    退職しました - みんからきりまで
  • Aimingでの3年間の日々と感謝 – Yoshiyuki Hirano – Medium

    2018年6月末で、2015年5月から(個人事業主としては2015年10月から)3年間ほど、業務委託でお仕事をさせていただいていた、株式会社Aimingとの契約が終了した(なので、この記事は契約終了エントリです)。 契機 契約開始時期は、京都で法人を構えていて、法人名義で仲介業者さんからご紹介いただき、契約が始まった。契約して数ヶ月してすぐに家族の入院し、仕事を継続することが困難になり、一ヶ月半ほど離れた時期もあったが、その後、法人を解散させて、個人事業主となり、その時またお声がけいただき、また途中、京都から鎌倉に転居したのだが、転居後も仕事をいただいて、この3年間を楽しく生きてこられた。 エンジニアとしての経験値 運が良かった。関東に比べて関西はエンジニアを採用しにくいという背景があったのかもしれなかったが、人材会社さん経由で紹介していただき、自分が書いたアプリケーションのコードの一部を

  • GentooのGitHubがクラックされてrm -r /入ってたそうだけどやばいの? - Gentoo metalog

    GentooGitHub リポジトリが乗っ取られて, 復旧作業のためアクセスできなくなってますね. infra-status.gentoo.org どうやら ebuild (パッケージビルド&インストールするためのbashスクリプトファイル)に "rm -rf /*"とかもしこまれていたとか. なんか見た感じやばそうだけど, 実際のところやばいんでしょうか? まあ, もちろんのっとられたからにはやばいし, しばらく該当 GitHub リポジトリを避けておくのがいいんですが, 実際どのぐらいなにが起きるぐらいやばいんでしょうか? ということで, 以下の話をします. やられたリポジトリがやばくない ミラーだから, 開発者は使わないよ いろいろないから, 一般ユーザも普通使わないよ プルリク受けつけと、まあバックアップぐらいのとこだよ 書かれたコマンドがやばくない ebuild の先頭に

    GentooのGitHubがクラックされてrm -r /入ってたそうだけどやばいの? - Gentoo metalog
  • Slack、全ユーザーが接続できなくなった大規模障害の原因はバッチ処理にバグがあったためと報告

    チャットサービスを提供するSlackは、太平洋夏時間の6月27日午前6時30分(日時間6月27日午後10時30分)頃から約3時間、全てのユーザーでSlackが利用できなくなる深刻な障害に見舞われました。 同社はその後、障害についての報告をステータスページに掲載。障害の原因が、データのバッチ処理に含まれていたバグであったことを明らかにしました。 同社の報告の一部を引用します。 On June 27th (yesterday) between 6:33 a.m. and 9:49 a.m. PDT Slack experienced an outage where people could not connect to their workspaces. The network problems were caused by a bug included in an offline batc

    Slack、全ユーザーが接続できなくなった大規模障害の原因はバッチ処理にバグがあったためと報告
  • Twitter での6年間 #3|Satoshi Nakagawa

    (Twitter での6年間 2 からの続き) 秋になると、上のほうが「Twitter は mobile centric company になる」という方針を打ち出した。つまり、それまではずっとウェブ中心の会社だったのを、これからはモバイル中心にシフトしていくという決意表明だ。その方針に従い、新機能を作るときにはまず iOS か Android に実装することが必須になった。もちろんプロジェクトに十分なエンジニアがいれば、ウェブも同時に実装してもいい。だが、これまでのようにウェブを先に作ってリリースしてから、あとで iOS と Android の実装を進めてリリースするということはしないことになった。その後のウェブトラフィックのかげり具合とモバイルユーザー数の伸びを考えると、いい時期のいい判断だったと思う。 そのころ、1人の男性エンジニア育児休暇で10週間の休みに入っていた。少ししてから

    Twitter での6年間 #3|Satoshi Nakagawa