5/23にヒカラボで登壇してお話させてもらった、一休.com レストランのレガシー改善でVue.jsを導入した体験談です webpack導入話も併せてどうぞ https://speakerdeck.com/japboy/legacy-development-meets-webpack
5/23にヒカラボで登壇してお話させてもらった、一休.com レストランのレガシー改善でVue.jsを導入した体験談です webpack導入話も併せてどうぞ https://speakerdeck.com/japboy/legacy-development-meets-webpack
The programming model in P is based on concurrently executing state machines communicating via events, with each event accompanied by a typed payload value. A memory management system based on linear typing and unique pointers provides safe memory management and data-race-free concurrent execution. In this respect, P is similar to modern systems programming languages such as Rust (opens in new tab
こんにちは。 pixivの投稿ユーザ向けグロースを担当しているエンジニアのsestaです。 4月28日、ISUCON6本戦の問題を作ったedvakf、catatsuyと一緒に第2回社内ISUCONを開催しました! ISUCONとは3人までのチームで参加し、与えられたウェブアプリケーションのチューニングを制限時間いっぱい行い、パフォーマンスに基づいたスコアで競いあうコンテストです。 去年の社内ISUCON開催記事に引き続き、 今年は当日の様子のレポートとベンチマークなどの全体構成について紹介します。 当日の様子 今年は38人もの社員が参加し、その中にはなんと、ビジネス職の新卒や人事(!?)も参加していました。 競技時間は10:30から18:00までと本番のISUCONと同様にしました。 10:30によーいどんで始めた社内ISUCONですが、前半はなかなかスコアを伸ばすチームが現れませんでした
左右2台のカメラで撮影した画像から、色々な形式のステレオ画像を作成、表示するソフトです。裸眼用左右横並び、赤青メガネ用アナグリフ、インターレース用はもちろん、液晶シャッターメガネを使ったページ切り替えノンインターレース方式の立体表示機能も内臓しています。 1台のカメラでも、撮影位置を左右少しだけ変えて2枚の写真を撮影することにより、手軽に立体写真が楽しめます。 デジカメ等でラフに撮影した画像も、左右の位置合わせはもちろん、角度修正も簡単にできます。また、左右画像の同じ位置を同時に切り出すトリミング、サイズ変更、画像枠の追加、テキストやロゴ画像の追加、360°パノラマ自動横スクロール等々、ステレオ写真愛好家必携のツールです。 ステレオフォトメーカーの使い方(初級編) ステレオフォトメーカーProがMacOS上で動作するようになりました(2021/12/27) Apple Silicon M1
はじめに ELB上でSSL証明書の設定をしている状態で、http(80)で来たアクセスをhttps(443)に転送したい話しです。 困った事 httpsでサービスを展開したいので、httpアクセスはhttpsにリダイレクトしようと思って、こちらを参考にNginxのconfにreturn 301 https://$host$request_uri;を書いてみました。 しかし、ELBで443を80に転送される設定がある状態でこれを書くと、当たり前の話しですがリダイレクトループが発生します。 状況として ①80で待ってるNginxにアクセスが来る ②returnの設定に従ってhttps(443)に転送 (つまりELBに戻る) ③また①に戻る これが繰り返されます やった事 ELBでリダイレクトされるとX-Forwarded-Protoというヘッダーを持ってNginxに到達します。 例
新しい技術を学びはじめるとHello Worldのその先で何を作るか詰まってしまうことがよくある。 最初から作りたいものがある人はそれ作ったほうがいいし、実務で導入できたりするなら一番手軽で学びが多いのだが中々そうもいかないのが人生というもの。 そういう人にとってはHello Worldからある程度使えるもしくは本番投入時に選択肢にできるレベルになるための道筋があると便利だなーと思う。 自分はWeb系の人間なのでフロントエンド/サーバーサイド/モバイルアプリという感じでまとめてるが、インフラ屋やハード他デザイン系の技術はまた違うと思われるのでこれはあくまでも自分の場合はということで。 共通 言語機能を一通り試す(A Tour of Goみたいな感じで) 基本的な型/制御構造/IO周り/クラス/文字列操作/正規表現/よく使いそうな標準ライブラリ その言語固有の機能は重点的に(goだったらgo
SREの@deeeet です。 MercariではSlack Botを使い様々な業務の自動化を行っています。例えばメインのAPIのReleaseはBotによる自動化がされており、JPとUSとUKの3拠点で1日に10回以上のReleaseをSlack上で実現しています(これ以外にも多くの事例があります)。 これまでのSlack Botは基本的には文字ベースでのやり取りが普通でした(グラフなどの画像を返答として利用することはあります)が、SlackはよりInteractiveなやりとりを実現できるInteractive Messageという仕組みも提供しています。これによりButtonによる決定やMenuによる選択といったアクションをユーザにとらせることができるようになります。 Buttonの仕組み自体は古くから提供されていましたが他のTeamへの配布が前提でありOAuthの仕組みを準備する必
いつもQiita、Qiita:Teamをご利用いただきありがとうございます。 Increments株式会社代表の海野です。 先日公開いたしましたQiitaのコミュニティガイドラインに関しまして、沢山のフィードバックをいただきありがとうございます。 ご意見を確認させていただく中で、ガイドライン内の表現に分かりにくい点があること、また、私達がお伝えしたいと考えていることについて、ユーザーの皆様へ補足すべき事柄があると認識いたしました。 お寄せいただいたご意見の中から代表的なものについて、Q&A形式で以下にご説明させていただきます。 なお、解釈に幅のある内容に関して、コミュニティガイドラインを理由に私達が一方的な対応を取るのは望ましくないと考えています。例えばコミュニティの中で内容について議論しやすい仕組みを導入するなど、よりユーザーの皆様に分かりやすい運営方針やサービス設計となるよう検討を進め
非常に興味深いお話でした。 古本を入手して読んでいるところですが、他の話も興味深く、人情味ある筆致が魅力的です。 絶版なのがもったいないですね…。 ※「お忍び」は違和感がある、というご指摘を複数受けたことを踏まえて、タイトルを若干変更致しました(文字数は変更なし)。 続きを読む
このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。 CROSS2016に出るので、最近の自分の考えを整理しておく。 最近ReduxのSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの本題はアプリの状態管理の話。 アプリは大きなシングルトン iOS、Android共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えば ユーザーのログイン情報を集約するUserManager コンテンツへのいいね情報を集めるLikesManager ブックマーク情報を集めるBookmarkManager などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵U
様々な事情があってしばらく自宅警備員をしながら転職活動をしていたのですが、ようやく落ち着いたので書いています。 タイトルちょっと煽り気味ですが、今回の転職活動では20社くらいの話を聞いたりしていました。 そこで「なるほどなぁ」って思うこともあったのでちょっとまとめてみようかなと思った次第です。 記事をを書くにあたっての前提として、自分のステータスですが 後期アラサーなので社会人経験も人生経験がそれなりにあり、第二新卒ではもうないし、「若手」とも言えずベテランに片足突っ込んでる感じ 人材紹介会社にいたりコミュニティにいたり採用人事やってたりなどしているので、IT業界の他社のことはなんとなく情報が自動的に入ってくる (転職活動の中で気づいたことだが)経験年数の割にどうやら仕事上の修羅場経験はそこそこある 今回は人事とかバックオフィスとかのいわゆる「ビジネス系職種(エンジニアではない)」で転職活
「Google I/O」も無事(でもありませんでしたが)終わったということで、Google周辺の動きを追うゆるい連載をはじめます。 Google I/O、“無事でもありませんでしたが”というのは、2日目に軽食コーナーで火災が起きて一時進行停止したからです。 この連載ではこういう、メインではない話もしていこうと思っています。 1999年創業のアイティメディアにとって、1998年創業のGoogleは(一方的に)ずっとその成長を見てきたIT企業。当時はMicrosoftやAppleに肩を並べる大企業になるとは思いませんでしたが、「自分たちの興味を追っていたら結果的に起業することになっちゃった」という感じの若きラリー・ペイジとサーゲイ・ブリンはとても魅力的でした。
potatotips #31での登壇資料となります。 昨年あたりからiOSアプリの開発やサンプル作成等に取り組んだ際の自分なりの方法や考え方・進め方についてまとめてみました。 (コードがほとんどなくって恐縮ですが宜しくお願いします) このスライドでピックアップしているコード&ノウハウ 成果例1: 日本の祝祭日付カレンダーサンプル(祝祭日ロジック) Github: https://github.com/fumiyasac/handMadeCalendarAdvance Qiita: http://qiita.com/fumiyasac@github/items/33bfc07ad36dfffcdf8f 成果例2: WebViewでのグラフとネイティブの合わせ技(カロリー記録アプリサンプル) Github: https://github.com/fumiyasac/WebViewGraphOf
Holiday デザイナーの多田です。 皆さんは Web アプリやモバイルアプリを開発する時、モックアップ作成にどれだけ時間を割いているでしょうか?もしくはモックアップを作成せずにすぐに実装に入るでしょうか?私はこれまで Web アプリ開発ではいきなり実装に入ることが多かったのですが、Holiday iOS アプリ の開発では Web アプリの時のように上手くいかないことに気づき、やり方を考え直しました。iOS アプリ開発の過程で、モックアップ作成や実装をどのように捉えるか、具体的にどう行うか、ということが自分なりに見えてきたので、それらについてご紹介します。 目的は、価値のあるプロダクトを速くユーザの手に届けること Web アプリやモバイルアプリの開発過程においてモックアップなどを作る目的は、あくまでも ユーザに届く プロダクトの価値を高めてそれを速くリリースすることです。適切な前準備は
場違いすぎて自分がエイリアンに思えてくるような若い女性と子供のペアばかりの平日昼間のスーパーマーケットで懐かしい顔を見かけた。20年間実家に引きこもり続けているF。Fは僕と同じ歳なので現在43~4才。僕とFは小中高と同じ学校に通っていたけれど、同じ部活に所属したことはなく、数回にわたるロシアンルーレットじみたクラス替えを経ても《奇跡的に》一度も同じクラスになったことがない。誰にでもあると思うけれども、親友とは少し違う、一定の距離を置いて付き合っているような、ある種の緊張感漂う友人関係だった。唯一の共通項は子供の頃からピアノを弾いていたこと。一度だけ、どういう経緯でそんなことになったのか覚えていないのだが、高三の秋の放課後に音楽室に置いてあった埃の被ったピアノで、たまたま楽譜のあった「くるみ割り人形」を連弾したのは覚えていて、それはメタリカやガンズ&ローゼスで灰色に彩られた僕の高校生活のなか
anond.hatelabo.jp こちらを読んで色々と思うことがあったので、レス形式で書いてみる。 (最初に言っておくとDISではないです。共感できる部分も結構ありました) ・一か月に50件や100件を超える申し込みをしている ・とりあえず申し込んでからキャンセルする ・同じ日に複数のイベントがあろうと、とりあえずエントリーする ・抽選で受かったイベントだけ残して、あとをキャンセルする これだけだけならまだ良いのでは。 キャンセルしてくれるだけまだ良い。 ・抽選で受かっても高確率でキャンセルする ・そして、イベント当日は高確率でドタキャンする ドタキャンはなるべくやめていただきたいけど、仕事の都合などで本当に行けなくなる場合もあるので難しいところ。 自分が主催者側になる際は、あらかじめドタキャン率を考慮するようにしてます。 イベントではほとんど質問をしない or 自己アピールのための的外
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ではアプリ
待望されたYarnサポートの入ったRails5.1が2017年4月にリリースされました。 Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides 他にもjQueryがデフォルトdependencyから外されたり、Optionalでwebpackサポートが入ったりしており、Railsのフロントエンドは大きな転換点を迎えたと言ってよいでしょう。本エントリではRailsのフロントエンド技術の今を振り返り、今後どうなっていくかをまとめてみたいと思います。 DisられてきたRailsフロントエンド Railsのフロントエンド技術スタックは、フロントエンドを専業とするエンジニアにDisられるものでした。具体的には下記の技術要素です。 jQueryCoffeeScriptAssets Pipeline (sprockets)gemのエコシステムに乗っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く