Wantedlyは、運命のチームや仕事に出会えたり、人脈を広げ、ビジネスの情報収集に使えるビジネスSNSです。
Quiver is a notebook built for programmers. It lets you easily mix text, code, Markdown and LaTeX within one note, edit code with an awesome code editor, live preview Markdown and LaTeX, and find any note instantly via the full-text search. Mix text with codeA note in Quiver is comprised of cells --- snippets of text, code, Markdown, LaTeX (via MathJax) or diagrams (sequence diagram, flowchart). Y
(English version here) 技術部モバイル基盤グループのヴァンサン(@vincentisambart)です。今日は最近作ったツール「Dokumi」の話をしようと思います。 紹介 他部署のエンジニアの仕事をもっと楽にすることが、技術部の重要な目的の1つです。その中で、Dokumiはモバイル開発者のコードレビューの負荷を減らすためのツールです。 なぜ「毒味」という名前にしたかと言うと、人間がレビューする前に、コードに毒(バグ、不自然なコードなど)が入っているかどうか毒味するツールだからです。別の言葉で言うと、少し進化したCI用のlintツールですね。pull requestが出る度に、Jenkinsがそのpull requestにDokumiをかけます。現在はDokumiはiOSアプリだけに対応してしていますが、今後はAndroidアプリへの対応も考えています。 現時点でDo
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
iOSエンジニアのみなさん、こんにちは! WantedlyでiOSアプリ開発を担当してます、杉上です。 このブログでは新規でiOSのアプリ開発を開始するなら、どうなふうに作ろうかなと妄想してみました。なかなか仕事の現場では新規アプリ開発の機会はないので、こういう妄想を常に膨らませつつプライベートで実験的にアプリを作ってみたりしています。 ( ここでご紹介する内容はiOSアプリを作るにあたっての最適解でもベストプラクティスではありません。プロジェクトのゴールや規模など多様な要因により構成もケースバイケースになると思うので、ご参考までに。) Embedded Framework活用(ターゲット分割)アプリの一部のコードをドメインごとにターゲットへ分けてEmbedded Frameworkとして利用することで以下のメリットがあります。アプリ開発が進んでからコードを分けるのは難しいので開発初期の段
綺麗にコミットしてますか?? はじめまして!Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何? Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
ご覧のとおり、9月に発売された、iPhone 6と6 Plusはディスプレイサイズが変わっています。またiPhone 6 Plusは、デバイス・ピクセル比が3.0となっており、@3xの画像が必要になります。これまで開発者は、3.5インチと4インチの縦幅の部分だけ意識していればよかったのですが、iPhone 6と6Plusが発売されたことにより、4.7インチと5.5インチも意識して開発する必要があります。対応していなくても表示はされますが、6Plusでは画面の表示項目は変わらず、画面の表示部品が大きくなり、らくらくフォンのようなUIになります。その為、iPhone 6への最適化、iPhone 6 Plusへの最適化が必要なのかも含め検討が必要になります。iOS 6から導入されたAuto Layoutが、ここに来て必須の技術となってきました。画面固定の場合は、そこまで意識しなくても問題が発見さ
Swagger places API specifications such as OpenAPI, AsyncAPI, and JSON Schema at the core of its architecture, which are crucial for guiding teams through the entire lifecycle of API design and documentation. This strategic focus ensures that our suite, including open source tools and SwaggerHub, delivers unparalleled efficiency and a seamless user experience. Explore the API Specifications Discove
自分が他社のiOSアプリ開発者と話す時にいつも同じことを聞いていたのでそれをQiitaにまとめていましたが、実際に他社の開発の現場でインタビューをしてくるというシリーズになりました。 記念すべき1社目はユビレジ社! ユビレジとはなにか 私の分かる範囲でユビレジというものについてすごく平たく説明すると、iPadを利用したお店のレジとそれを管理するウェブ上のシステムみたいな感じだと思います。そもそもお店のレジスターっていうものは単純な売上の計算のためだけのものと、商品や顧客情報をひもづけるPOSレジ(POSはPoint of sale)と呼ばれるものがあって、このPOSレジをiPadとウェブで実現するぜ!ということでしょう。 訊いてきたこと ユビレジ社ではiOSアプリ開発をしている人で知らない人はいないという@kishikawakatsumiさんと、インターネットで有名な@laisoさんを中心
「実践現場から学ぶモバイル開発の勘所とビジネスへのインパクト」をテーマとしたセミナーが、2015年10月に開催された。その講演の概要を紹介する。 クックパッドのモバイルアプリにおける開発体制・ソースコード管理・CI レシピサイトとして有名なクックパッドは、世界有数の巨大なRailsアプリと言われている。そのサービス開発、特にモバイルアプリの開発体制と、ソースコード管理やCIについての実践を、クックパッド株式会社 技術部モバイル基盤グループ エンジニア 藤 吾郎氏が紹介した。 なぜモバイルファーストなのか クックパッドは社名であると同時にサービス名でもある。サービスは自社開発なので仕様を決めるのは社内の開発チームで、バグのトリアージも開発チームが行う。また、B2C製品なので使い方をユーザーに強制できない。例えば、開発者側では最新の端末、OSで使って欲しいが、それを強制することはできないという
チーフエンジニアの id:Songmu です。 4月に 新人エンジニア研修を行なった のですが、その際に、「インフラを意識したアプリケーションの書き方」という講義を担当しました。そこでおこなった講義の内容について整理しながら書き起こしていきたいと思います。 インフラを意識すると何が良いか 業務でWebアプリケーションを扱うと、個人ではなかなか扱えないトラフィックであったりデータ量を扱うことになります。小規模サービスでは考えなくてよかった多くのことを考慮する必要がでてきます。なかなか体験できないことでもあるので、楽しく、やりがいもあります。 また、そういった経験を通して、インフラを意識しコードをかけるスキルを身につけることは、Webエンジニアとしては大きな強みとなります。ISUCONで優勝できるかもしれません*1。 インフラを意識すると何が良いか 〜 中規模ベンチャーの場合 そもそも、はてな
2013年11月18日 追記 この記事を書いた後、何人かのかたから「うちでは同じApple IDで両方とも使えているよ」というご指摘をいただき、 Member Centerのほうにアカウント追加 -> iTunes Connectに同じアカウント追加という順番だと「警告は出るもののかまわずContinueすれば」同じApple IDでアカウント作成可能 iTunes Connectにアカウント追加 -> Member Centerに同じ追加という順番だと「複雑な手順にはなるものの適切な手順を通せば」同じApple IDでアカウント作成可能 失礼しました。 追加情報などあれば是非おねがいします! 概要 私はiOSアプリの開発を3年以上やっていますが、恥ずかしながら会社でこのためのアカウントを管理/運用する方法をきちんと把握できていませんでした。 というのも個人で開発するぶんにはそんな管理は必
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』 こんにちは、谷口です。 ディレクターやプロジェクトマネージャーといった非エンジニア職の方々は、エンジニアとコミュニケーションをとることに難しさを感じたり、考え方にギャップを感じたりしたことがある方もいらっしゃるかと思います。 「エンジニアとわかりあえない…」「エンジニアが何を考えてるのかわからない…」という方のために、エンジニアとのトラブルのもととなるやりとりや、気を付けるとよいことを考えていきますので、非エンジニアの方々の参考になればと思います。 ■「どれくらいでできる?」はその場で決められるものではない 非エンジニアとエンジニアのもめごとの原因で多いのが、スケジュールに関することです。 非エンジニア「この機能どれくらいでできる?」 エンジニア「一日でできます」 非エンジニア「じゃあ明日リリース
2016.05.17AbemaTVのランタイムパフォーマンスのAudit最近業務で、巷で話題のAbemaTVのパフォーマンス改善をしている。個別具体性が高いが調査改善の雰囲気を感じ取ってもらえればそれで良いかと思い、記事にした。 AbemaTVのフロントエンドの構成話の前提となるAbemaTVのフロントエンドの構成は次の通りで、まさに流行りのといった感じ。 facebook/reactfacebook/immutable-jsReactive-Extensions/RxJSreactjs/react-routercss-modules/css-modulesビルド周りはbabelとwebpack、あとはlintツールがちょこちょこ入ったりしている。この改善の話と関係してくるのは、ReactとImmutableJSとRxJSだけ。 番組再生画面のコメント開閉が重い今回ケーススタディとして挙げ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く