namaninotiteti1026のブックマーク (295)

  • Android 4系(API16-19)のTLS1.1, 1.2対応 - 怠惰を求めて勤勉に行き着く

    TL; DR API16-19はデフォルトでTLS1.1, 1.2が有効になってないので適宜ONにしてやる TLS1.1, 12を有効にしたとて、強いCipher suitesが使えるかは別問題 知ってる人は知っている。知らない人は覚えてね。 前口上 さて、iOS 9からTLS1.2が必須になったのは記憶に新しい。このタイミングで社内のAPIサーバの設定が変わって芋づる式に対応に追われたAndroiderも少なくないはずだ。 件、僕自身もすぐ忘れるのでAndroid 4系(API16-19)のTLS1.1, 1.2対応について改めてまとめておきたい。 Default configuration for different Android versions に書いてあることが全てなんだけど、AndroidAPIレベルとSSL/TLSの関係は次のとおりだ。 SSLv3…使うな TLSv1…

    Android 4系(API16-19)のTLS1.1, 1.2対応 - 怠惰を求めて勤勉に行き着く
  • 小野和俊のブログ:プログラマー風林火山

    アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニア仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ

    小野和俊のブログ:プログラマー風林火山
  • express-graphql + vue-apollo で GraphQLを試してみた | PLAID engineer blog

    API用の技術として注目されている「GraphQL」をexpress + Vueで実装して試してみました!

    express-graphql + vue-apollo で GraphQLを試してみた | PLAID engineer blog
  • イケてるAndroidオープンソースアプリ集 - Qiita

    PLAID Advent Calendar 2017 11日目の記事です。 メンテナンスされていてそこそこ規模が大きいAndroidOSSアプリのまとめがあまりないな、と思ったので探しながらまとめました。 明確な基準はありませんが参考になりそう(主観)で、次の条件を大体満たしていているものをいくつか挙げました。 スター1,000以上 最終コミット2カ月以内 英語 google/iosched Google/IOのカンファレンスアプリ。タグで2011-2017年版まで管理されてる 主な利用ライブラリ:Gson, FCM, LeakCanary, Espresso AbstractThreadedSyncAdapterやLoaderManager、ContentProviderを多用 MVPアーキテクチャ Calendar Providerによるスケジュール同期機能、TileProviderに

    イケてるAndroidオープンソースアプリ集 - Qiita
  • 技術選定の審美眼 / Understanding the Spiral of Technologies

    初演: 2018/02/15 デブサミ2018 15-D-1 ハッシュタグ: #devsumi #devsumiD https://togetter.com/li/1199564

    技術選定の審美眼 / Understanding the Spiral of Technologies
  • 新技術を学ぶ技術と三つの壁とDroidKaigi 2017 - Islands in the byte stream

    こないだの@onkさんのスライドがとても良かったんですよ。 短期間で新技術を学ぶ技術 from Takafumi ONAKA 短時間といいつつ守破離の「離」までいくのに3年かかるといってて、高速道路なんてものはないんだなということがわかりますね。 とはいえ自分自身に照らし合わせてみてもそのとおりだなと思いました。ぼくもAndroidで対外的にアウトプットできるようになるまで3年くらいかかってますし。まあ、ぼくは新技術を学ぶのはわりと苦手なほうではあるんですが。 で、スライドにはないけど新しい技術を学ぶ際には大きな壁がいくつかあるなとあると思ってます。それを 意識して 乗り越えるための指標としてもこのスライドはよさそうだなと。 ついでなのでちょっと ぼくの感じる 三大壁をまとめてみました。まあ、壁を壁と感じない人もいると思いますけどね! Lv.1 着手の壁 症状: 何の役に立つのかわからない

    新技術を学ぶ技術と三つの壁とDroidKaigi 2017 - Islands in the byte stream
  • WP-Kyoto

    ESLintを入れておくと、タイポやイレギュラーな書き方をすぐに見つけることができて便利です。 ということで、ReactコンポーネントをESLintAirbnbルールセットでリファクタリングしてみましょう。 リント対象コードを作る 対象のファイルを作っておきましょう。 今回は以前Jestの記事書いた時に使ったコードをネタにしてみます。 ExampleBtn.js import React from 'react' export default class ExampleBtn extends React.Component { render () { return ( <button type={this.props.type} > {this.props.children} </button> ) } } Jestでスナップショットテストを用意する リファクタリング時に大規模なコードの

    WP-Kyoto
  • React Navigationで画面遷移してみる - ushumpei’s blog

    React Nativeで画面遷移したかったのでまとめました。 内容としてはcreate-react-native-appで作ったアプリで、2つのナビゲーター(StackNavigator、TabNavigator)を使ってみた勉強記事です。 注意としてはDrawerNavigatorは使わないことと、redux等との連携も書いてないことです。 記述方法等は公式ドキュメントをご確認ください。 概要 公式ドキュメント で紹介されている画面遷移用のライブラリはいくつかありますが、 クロスプラットフォームで動作するものと考えると選択肢に入るのは以下の二つかなと思いました。 二つとも綺麗なドキュメントが用意されています。 React Native Navigation React Navigation どちらを選んでもよかったのですが、 create-react-native-appで使ったアプリ

    React Navigationで画面遷移してみる - ushumpei’s blog
  • Apollo Clientを使ってみるチュートリアルのようなもの - ushumpei’s blog

    React #1 Advent Calendar 2017 12日目の記事になります。 GraphQL!(こんにちは) この記事はGraphQLのライブラリ React Apollo を使って、ReactGraphQLを触ってみようという内容です。 GraphQLどうなんでしょうか? 運用で使って見た系スライドとか公開してくださっている方々がいたりしますが、なかなか敷居が高そうで手が出せていませんでした。主に サーバーの実装がよくわからない、という理由です。 そんな時Full-stack React + GraphQL Tutorialという Apollo公式チュートリアル を見つけて、よしやろう、と思ったのですが、 apollo-clientのバージョンが変わって内容が合わず苦労した ので、そのあたりを自分なりに書けたらと思います。 GraphQL自体に関しては以下のリンクで勉強しまし

    Apollo Clientを使ってみるチュートリアルのようなもの - ushumpei’s blog
  • ReactNativeで理解しておくと良いReduxとMiddlewareのフローを理解する - tomoima525's blog

    (5/29/2017追記 ‘必要不可欠’ とタイトルに書いていたら'必要不可欠でない'と指摘を受けました。なんらかのデータフローの仕組みは必要だけどReduxである必要はないのでタイトル修正しました) 最近ReactNativeをちょこちょこ書いています。アプリ向けのReactNativeを書くにあたって理解がのぞましいのがデータフローの仕組みであるRedux、及び様々な処理を仲介するMiddlewareです。小さなアプリをつくってみて一通り把握したので、整理も兼ねて初めてReact-Reduxを触れる時にどの辺を見ればよいかまとめてみます。 作ったのはChuckNorris FactsのJokeを検索して表示するアプリです。 github.com デモ動画 昨日のReactNativeアプリ続き。Reduxにローディングのステートも追加してみた。iOSとAndroidでも想定通り動く。

    ReactNativeで理解しておくと良いReduxとMiddlewareのフローを理解する - tomoima525's blog
  • DroidKaigi2018にスタッフとして参加したらいろいろとすごかった - BASEプロダクトチームブログ

    Androidアプリエンジニアの鈴木 (G_devi) です。 今まで何回かDroidKaigiに参加はしていたのですが、今回のDroidKaigi2018は初めてスタッフとして参加させていただきました。 その中で、運営・進め方・情報管理・当日の動き・臨機応変な対応など、いろいろとすごいなーとか、このやり方いいなーとか思ったことがあったのでお伝えしたいと思います。(書ける範囲で) すごかったこと・いいなと思ったやり方etc... どれが一番とか選べないので順番は特に関係ないです globalチームがある 簡単に言うと、英訳してもらいたい文をここにお願いすると分かる人が翻訳してくれる感じです。 DroidKaigiは海外からも参加者や登壇者が来ますし、グローバルな対応が必要になってくるので何にでも英語が必要となります。 登壇者とのメールのやりとり、アンケートなど全体に投げるもの、海外サービス

    DroidKaigi2018にスタッフとして参加したらいろいろとすごかった - BASEプロダクトチームブログ
  • Baltoサービス終了の背景|Goodpatch Blog グッドパッチブログ

    Baltoはなぜ生まれたのか まず前提として、Goodpatchには、ProttやBaltoなどの自社事業をつくる部署とクライアントワークを担当する部署があります。そして、自社プロダクトにはクライアントワークで培った経験が活かされています。 Prottは、コードを書かずに物のようなWebサイトやアプリの動きを再現できるサービスです。しかし、実際に実装し始めると、大きな手直しは少ないものの、細部では直したい部分が続々と出てきます。 それをどのようにメンバー間で伝えるかというと、モバイルでスクリーンショットを撮影してPCに送り、スプレッドシートやパワーポイントで指摘部分の説明資料を作る必要がありました。この方法では、1回のフィードバックに60秒くらい時間を要し、かつ単純作業なので、繰り返していくとフィードバックが億劫になっていきます。 そうすると細かいフィードバックをつい放置してしまい、結局

    Baltoサービス終了の背景|Goodpatch Blog グッドパッチブログ
  • Proton Native - React Native for the desktop, cross compatible

  • 2週間半のReact Nativeアプリ開発を振り返る - c-bata web

    React Native+Expoではじめるスマホアプリ開発 ~JavaScriptによるアプリ構築の実際~ 作者: 松澤太郎出版社/メーカー: マイナビ出版発売日: 2018/08/29メディア: 単行(ソフトカバー)この商品を含むブログを見る ここ2週間ちょっとReact NativeでiOSアプリ書いてました。 サーバサイドをメインでやってきた自分にとって面白い技術で、今後も趣味で使ってみたいなと思えているのでTipsや所感を残しておきます。 目次 選定理由 Tips エラーハンドリング・状態管理 入力欄をキーボードの出現に合わせて動かすアニメーション 今回使ったライブラリ react-native-focus-scroll react-navigation react-native-vector-icons react-native-camera react-native-vid

    2週間半のReact Nativeアプリ開発を振り返る - c-bata web
  • React Native開発のつらい点まとめ – MMiyauchi Blog

    React Native v0.42で開発していて、つらい点を述べていく。良い点はあったかもしれないが、忘れてしまった…(良い点含めたより公平な意見は、あらためてまた今度書く  2018年2月28日追記: 書きました!!→ React Native開発の良い点と注意点まとめ)。 なお、製品でReact Nativeを運用されている方で、他にもつらいとおっしゃっている方もいるようなので、自分がReact Nativeに対して感じているこのつらさは間違っていないと思う。 大前提として「React Nativeは、Viewしか扱わないReactがベース」である これがそもそものReact Nativeがつらいと思える根的な原因かもしれない。React Nativeのコンセプト通り、React Nativeではたしかに、Reactの知見をほとんどそのまま流用してReact Nativeではアプリ

    React Native開発のつらい点まとめ – MMiyauchi Blog
  • 僕にとってのDroidKaigiがどんなに面白い場所なのか書く日記 - ひつじのにっき

    ひつじです。 DroidKaigiおわったんですよ。みなさん、おつかれさまっした!!!!!!! このエントリはブログタイトルどおり、ひさしぶりの個人の日記並の感想文です。読んでも得られることは、ひつじのひととなり*1がわかる以外のメリットは無さそうです。 1000人規模のイベント(珍しい規模だけど特別ではないと思う)をどうやって運営したかという部分も興味があるひといるかもしれないので、ちゃんとしたまとめは別途やるかもしれないけど今回は、この一年間オーガナイザーとして関わってきたDroidKaigiが終わったあとの感想文です。読み進めてもヤマとオチはないので理解いただきたい。なお時系列も無視されているので気をつけて。 DroidKaigi 2018が終わった夜と、はじめてのDroidKaigi DroidKaigi 2018が終わった2月9日の夜、スタッフでささやか*2に打ち上げた帰り道。

    僕にとってのDroidKaigiがどんなに面白い場所なのか書く日記 - ひつじのにっき
  • DroidKaigi2018で発表したFlutterアプリの話のスライド補足 - Konifar's WIP

    DroidKaigi2018で『コードで見るFlutterアプリの実装』というタイトルで話をしてきました。 speakerdeck.com 聞きに来ていただいた皆さん、資料を読んでフィードバックをくれた皆さん、運営の皆さん、発表前に場を温めていただいた @mhidakaさん、ありがとうございました。 スライドだけだと話がわかりづらいところもあると思うので、書き起こし形式で補足しておこうと思います。当日用のスライドを一部削ったり、アドリブの台詞を省いたりはしています。 ちなみにこのやり方は、@yanzmさんが去年、今年にやっていてとてもよいなぁと思ったので真似させていただきました。 コードで見るFlutterアプリの実装 今日はFlutterアプリのコードの話をします。Flutter自体の内部の詳しい実装ではなく、Flutterでアプリを作る時にどうコードを書くのかという話です。よろしくお願

    DroidKaigi2018で発表したFlutterアプリの話のスライド補足 - Konifar's WIP
  • シンプルタスク管理アプリ『tasemo』をリリースしました - ゆっくり書くブログ

    2018年の目標『アウトプット』の第一弾として、タスク管理アプリ『tasemo』をリリースしました! リリースしたのは1/30なので1週間以上前ですが、リリースしてから嬉しかったこと・学んだことがあったのでそれを書きます。 tasemoって何? 当にシンプルなタスク管理アプリです。やることを『Todo』に追加、終わったらタップして『Done』に移動するだけです。 ふとやらなきゃいけないことを思いついた とりあえずやることをパッとメモしたい やったかやってないかわかればいい といったシーンで、日々の細かいタスクをパッと管理できます。 tasemo Shizuna ItohProductivityFree なんのために出したの? 一言で言うと「自分のため」なのですが、2つ主な理由があります。 1、RxSwiftとRealmを学びたかった これがこのアプリを作ったきっかけです。 1月に「RxS

    シンプルタスク管理アプリ『tasemo』をリリースしました - ゆっくり書くブログ
  • 深く考える訓練、その1|深津 貴之 (fladdict)

    大学の授業用のサブ教材として、生徒に「深く考える」トレーニングの資料を作ってる。 思考力というのは、トレーニングで伸ばすことができる。トレーニングでは、まずは自由な思考よりも、フレームワークを使い倒すことが重要だ。数をこなせば、考えることが苦ではなくなる。それが一番重要だと思う。基的なトレーニングができていない状態で、自由に発想させても、大半の人は途方にくれてしまう。 ここでは何回かのシリーズを通じて、段階的に複雑なことを思考するためのフレームワークを紹介していく。 まず第1回目は、シンプルで誰でもつかえるフレームワーク、The Five Whys(5つのなぜ?) だ。 「5つのなぜ?」ものごとについて、5回「なぜ?」と深堀りをする。 The Five Whys(5つのなぜ?)は、たったそれだけのシンプルな思考ツールだ。 大抵の人間は、2〜3段階深く以上ものごとを考えられない。いままでの

    深く考える訓練、その1|深津 貴之 (fladdict)
  • DroidKaigi2015に行ってもっとAndroidやりたくなった - Konifar's WIP

    DroidKaigi2015に行ってきました。 すごく濃いセッションばかりで学びしかなくて、考えたことを吐き出さないと忘れちゃいそうなので、ざっと書き留めておこうと思います。 セッションごとの感想はたぶん色んな人がブログやらQiitaやらに書くと思うので、自分が考えたことベースで書いていきます。 コードメインの発表の楽しさ @mhidakaさんがWelcome Talkの中で 『DroidKaigiはエンジニア主役のカンファレンスです』と言っていました。その精神が浸透していたからか、セッションもコードメインの話が多く、すぐにでも試してみたいとムズムズするものばかりでした。 例えば勉強会のマテリアルデザインの話なんかだと概念の話で終わってしまうこともあって、それももちろん勉強になるんですけど、やはりコードを見ながら話を聞いた方が面白いなぁと思いました。JakeのDagger2の発表なんかもほ

    DroidKaigi2015に行ってもっとAndroidやりたくなった - Konifar's WIP