サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
hiragram.hatenablog.jp
ボートレース戸田の様子 前回: クックパッドを退職しnana musicに入社しました - hiragram no blog こんにちはー。 2024年1月末をもって前職を退職し、2月からakippa株式会社で働いています。3ヶ月の試用期間を経て5月以降も雇用が継続される見込みとなったので、この記事を書いています。 謝辞 前職には2022年2月から2024年1月までのちょうど2年間在籍しました。自分と家族の状況変化と、仕事で負う役割や会社そのものの変化がたまたま近い時期に起こって、自分と家族が健やかに暮らすことを優先するためには環境を変える必要があったという感じです。 在籍中お世話になった同僚の皆様、ありがとうございました。一部の方には、急な告知のあとすぐ居なくなるような形になってしまったことをお詫びします。ご心配をおかけしてすみません。 今はakippaで働いています 一部の方にはまたか
ボートレース戸田の様子 こんにちはー。 2022年1月末をもってクックパッド株式会社を退職し、2月から株式会社nana musicで働いています。 6ヶ月の試用期間を経て8月以降も雇用が継続される見込みとなったので、この記事を書いています(書いてるのは6月末)。 みんな入社していきなり新しい会社を褒めちぎる転職エントリかけるの不思議だなーといつも思っています。 謝辞 クックパッドには2018年8月から2022年1月の3年半在籍しました。感染拡大第6波の最中の退職だったため、多くの方に直接ご挨拶できなかったのが悔やまれます。在籍中お世話になった皆様、ありがとうございました。 横浜移転による片道120分超の通勤時間と週2日のオフィス勤務の組み合わせに適応できなかったのが直接の退職理由です(退職時点での話。今はどうなってるか知らない)。 今はnana社で働いています 冒頭にも書いたとおり、2月か
スタートトゥデイテクノロジーズ(旧VASILY)を退職します。今日から有給消化です。 次は決まっていません。8月からiOSらへんの技術者として雇ってもらえる会社を探しています。 最近業務やら個人やらでやったことは以下の通りです RxSwiftの啓蒙 ビットコインのアービトラージ取引支援アプリみたいなやつ OpenAPI(Swagger)ドキュメントからAPI定義/モデル型定義のコードを生成する仕組みの開発 任意の状態のスクリーンショットを収集する仕組みの開発 消費型課金/サブスクリプション型課金の実装 CI周りいろいろ API/UserDefaults/Keychainなどの抽象層の設計、実装 try! Swift Tokyo 2018で型安全なWebAPIモデリングについてLT発表 その他細々した発表 今の所あんまりやりたいと思っていないことは以下の通りです 医療 金融 新しい環境に強く
この記事はVASILY Advent Calendar 2017の17日目の記事です。 また、以下の記事の続きです。 hiragram.hatenablog.jp アプリにJSONを返す部分を安全にする話を前回したので、今度は取引所のAPIを叩いてデータを取得するバッチを紹介する。 データ集めのバッチもVaporの Command の仕組みで動かしている(ここでは詳細は割愛するが、Vapor Cloudはcronもサポートしている)。 今度はバッチ側が取引所APIのクライアントサイドの位置付けになるので、まずは自作フレームワークAbstractionKit を用いて各取引所APIを抽象化し、RxのObservableを経由してデータを取得するクライアント層を作る。 Coincheckの売買価格を取得するAPIをこう定義する。 struct CoincheckEndpoints { stru
この記事はVASILY Advent Calendar 2017の9日目の記事です。 目指すのは労働からの引退。 VASILY開発合宿で取り組んだ内容です。 何を作りたいのか ビットコインの売買価格は取引所によって異なる。そこで、安い取引所で買って、すぐに高い取引所で売ることができれば、ビットコインそのものの価格変動に左右されずに利益を得ることが出来る。これがアービトラージ取引である。 今回は、複数の取引所のAPIを叩いて定期的に売買価格を取得するサーバーサイドアプリケーションと、その情報を表示するiOSアプリケーションを作った。 システム構成 サーバーサイド 言語: Swift Webフレームワーク: Vapor インフラ: Vapor Cloud バッチ処理の一部にRxSwift iOSアプリ Swift, RxSwift, APIKit その他 サーバーサイドのAPIとモデル型はSw
習作としてレシピのマスターデータがあってそれを作ったよというレポートをアプリから投稿できるようなやつを作ってみて感じたこと。 とりあえず動かすのが超簡単 コンソールからプロジェクトつくってキー発行してSDK入れて初期化すればDBにアクセスできて簡単だった。 考えなしに使うと多分いろいろ破綻する DBがスキーマレスなのでなんでもぽいぽいpostできちゃう DB操作する所は1箇所にまとめて抽象化しないと欠けたオブジェクトがDBに乗っちゃったりして詰みそう。そこはSwiftのカチッとした型と柔らかいスキーマレスDBとの境界で大変というかんじ。考えなしに進めてオブジェクトのプロパティがどんどんOptionalになっていくのは見ていられないので抽象化がんばりましょう 既にデータが刺さってるモデルにプロパティ追加したりしても古いデータは当然マイグレートされないので古いデータが落ちてきてパースに失敗する
3年2ヶ月在籍したSpeeeを退職します。今日が最終日です。 なにしてたの? 元々サーバーサイドのエンジニアとして新卒入社してPHPやっていて、自社サービスのiOSアプリ用のAPIを作ってました。そのうちアプリ側のちょっとしたデバッグとか修正をXcodeでやるようになり、アプリおもしれーなとなってきたタイミングで社内公用語がPHPからRubyになるとのことで、どうせ未経験から勉強するならRubyよりアプリやりたいなとなり転向させてもらいました。そこからはそのプロジェクトでObjective-Cを書いたり幾つかのプロジェクトでSwiftを書いたりしました。 取り組んだこととしては、 Swift1.xから2.0への移行 RxSwiftの導入 API抽象レイヤーの型々しい設計 TravisCI上でCarthageの依存フレームワークをキャッシュしたりCartfile.resolvedの差分をみて
以前ふとこんなツイートをしたところ意外とLikeされた。 AutoLayoutのエラーがコンソールに出た時意味不明だけどviewのaccesibilityIdentifierとconstraintのidentifierに任意の文字列入れておくとメモリアドレスの部分がそれに置き換わるのでおすすめ— 🙌🐼ひらり🐼🙌 (@hiragram) 2017年6月8日 AutoLayoutの制約に矛盾があるときにコンソールにでるメッセージ これをみて直さないといけないときに自分がやっていることをまとめておく。 ビューのaccessibilityIdentifierを設定する コードからならhogeView.accessibilityIdentifier xib/storyboardならここ。 すると UIView:0xXXXXXXXXXXXXと出てたところがaccessibilityIdenti
最近Segueをいかに安全に使って画面遷移するかということを考えていたけど、#swtwsを見ていてそもそもSegueを使わない/嫌いという人が結構いるんだなと思ったのでSegueを使わないで楽に安全に画面遷移する方法を考えてみたら意外といい感じになった。 Segueの危うい所 コード内ではSegueのidentifierを単なる文字列として扱う所 performSegue(withIdentifier: "toDetailVC", sender: nil) だからSegueの名前が変わった時に直し忘れていてもコンパイル時にチェックできない。 遷移先のViewControllerをいじるのはいわゆるprepareForSegueメソッドの中なので、複数の遷移に関する処理が一つのメソッドにまとめられてしまう所 override func prepare(for segue: UIStorybo
クソアプリ Advent Calendarの16日目です。 先日個人で作ったSushiCameraというアプリをリリースした。 hiragram.hatenablog.jp 個人で作ったアプリがストアリリースまで行ったのは初めてだったので、やる前の気持ちや今の気持ちを雑に書く。 クソアプリ作るぞ〜という気持ちがあって作ったわけではなくて、「カメラ」「画像加工」あたりの技術に触りたかったのでそのために雑に作ったという感じで、大衆にウケようとか収益化しようみたいなことは一切考えてなかった。 もともと今まで関わってた(or関わってる)アプリがステルスリリースだったりファーストリリース前だったりして「私の作品はこれです」といえるものが無かったのもあって、せっかく作るなら他者から見える形で、1つのプロダクトとして最低限の体だけは整えようと思っていた。テーマにした「カメラ」「画像加工」以外の例えばUI
https://www.raywenderlich.com/126522/reactivecocoa-vs-rxswift - Functional Reactive ProgrammingはSwift開発者の間でますます人気が高まってきている方法論である。それは複雑な非同期処理のコードを書きやすく、理解しやすくすることができる。 この記事では、FRPの中で人気のあるライブラリ、RxSwiftとReactiveCocoaを比較する。 まずはFRPとは何かを簡単におさらいして、そのあと2つのフレームワークの細かい比較を見てもらう。読み終わる頃には、どちらのフレームワークが自分にあっているか判断ができるようになっているだろう。 リアクティブに行こう! Functional Reactive Programmingとは何か? Note: もしもう既にFRPのコンセプトをわかっているなら、次の"R
私は英語チョットデキルになりたいので、そのためにチョットがんばることにしました。 去年の12月らへんからいろいろ始めて、だいたい2ヶ月くらい経ったので、やってることとかやったけどやめたこととか書く。 「ワタシハ リナックス チョットデキル」Tシャツを着るリーナス・トーバルズ(Linus Torvalds)の勇姿その2。 #Linuxcon pic.twitter.com/46eMSkUX4U— shigetaka@256将軍_発売中 (@shigetaka256) 2014, 5月 21 やってること エンジニアが0から英語を勉強する為にした事 に多大な影響をうけた。 DMM英会話 http://eikaiwa.dmm.com/ DMM英会話以外のオンライン英会話は試してないので、的外れだったらごめんなさい。 やってる中で一番英語っぽい活動はこれ。まだ始めて2週間くらいだけど、めっちゃ楽し
どうもどうも。1日に2度ブログを書くのは初めてです。 YAPC::Asia 2015のお土産でみんなもらったトートバッグにPerlのprint文が書いてありますよね? おみやげの内容については、さっき僕が書いた記事を御覧ください。 YAPC::Asia 2015のお土産を紹介するぞー #yapcasia YAPCにいる最強のPerlプログラマのみなさんはおそらく実行するまでもなく出力を読み取ることができたんだろうなあと思うんですが、僕はPerl力が無いので得体のしれないコードを無防備に実行してしまいました。すみません。 さて、トートバッグに書いてあったコードはこんな感じです。 print 115.117.112.112.111. 114.116.101.100.32.98. 121.32.76.105.118.101. 115.101.110.115.101.32. 73.110.99.4
今日前夜祭でした。明日からが本番です。 id:y_uukiさんのブログ論、とてもおもしろかったです。 僕は個人スポンサーチケットで参加したので、スポンサー特典も含めて頂いたノベルティを紹介しますー。 トートバッグ YAPC::Asiaの缶バッチもついてます。 Perlのprint文がべろべろ書いてある。気になる人は自分で実行してみてください。 追記: 記事書きました YAPC::Asia2015のトートバッグに書いてあるコードをいじいじする #yapcasia イベントパンフ と、タイムテーブル。 クリアファイル ステーションメモリーズ モバイルファクトリーさん。実はこれ貰ったの2枚め。 pixiv/岸田メル 裏には「お絵かき楽しす」って書いてありました。 アカツキさん 「ゲームには世界を変える力がある」かっこいい Tシャツ 茶色Tシャツ(一般) 両面プリント。背番号はみんな10です。 赤
このページを最初にブックマークしてみませんか?
『hiragram.hatenablog.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く