iOSDC Japan 2016の発表資料です。 https://iosdc.jp/2016/c/node/84
ユーザーに受け入れられ、問題を起こしづらい大規模リニューアルの進め方
iOSDC Japan 2016の発表資料です。 https://iosdc.jp/2016/c/node/84
土木の世界からインターネット業界に転身した女性として思うこと - Qiita
こんにちは、okaneyaです。 大学・大学院では土木工学を専攻し、この春卒業してインターネットサービスの会社に就職しました。この組み合わせは珍しいようなので、こちらの世界に来て戸惑ったことや考えたことについて書いてみようと思います。 「一旦リリースしてみよう」の文化に当惑した インターネット業界に来て一番当惑したのが、「完成形じゃなくても、一旦世に出してみる」ことができる点です。 橋やダムを「強度が不安だけどとりあえず作ってみようか〜」と言って作ることは絶対に許されません。人が死にます。然るべき手順を踏んで、多くの組織や人が関わって、綿密な計画の上にようやく着工のGOサインが出ます。 一方自分が今関わっているwebサービスは、最初から完璧に作り込まなくても仮説を検証するのに十分なだけのものがあればとりあえずリリースすることができます。まずは最小機能のサービスを作って、人に使ってもらって反
画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール | UXデザイン会社Standardのブログ
2014.11.19 / UI 画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール Tomohiro Suzuki クライアントやディレクターから渡された画面遷移図を元にワイヤーフレームを作ってみると、後から足りない画面が次々に発見された、または画面内の情報がどこに繋がるのか分からないといった経験はありませんか？ この画面遷移図というものは本来は制作範囲の全体像と構造を明確にし、必要な画面というものを洗い出したりするものです。通常のWebサイトであれば、従来のような画面遷移図でも問題ないかもしれませんが、多くのインタラクションが発生するサービスの設計では複雑化しやすく、何度も情報を行き来して確認することになるため時間がかかります。 原因のひとつとして、画面遷移図では画面名のみを記載して繋げていくことになるため、必要な情報が不足していることが挙げられます。その結果、本来で
GitHub の ATOM が CoffeeScript で書かれているのはどうなの? - ワザノバ | wazanova
http://discuss.atom.io/t/why-coffeescript/131 2 comments | 2 points | by noto ■ comment by noto | 約1時間前 先日 GitHub が発表してエディタ ATOM のディスカッション・フォーラムでなぜ CoffeeScript で書かれていて、EcmaScript 6 (ES6) じゃないの? node.js/V8 を利用するデスクトップアプリケーションなら ES6 をすぐに使うほぼ完璧な機会なのに、という問題提起があり、それについて議論があったようです。 前提として、GitHub の JavaScript Styleguide に 新たに JS を書く時は CoffeeScript で書くこと 新たに .js ファイルを追加することは避けること と書かれていて、GitHub の中の人としては
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
モチベーションを下げる罠、「アンダーマイニング効果」にご注意。 - 烏は歌う（はてなダイアリー跡地）
久しぶりの学習心理ネタ。 ○「アンダーマイニング効果」とは アンダーマイニング効果とは、 「外発的なモチベーション」が、「内発的なモチベーション」に「負の影響」を与えること です。 これだけだと、なんのことだかさっぱりなので、喩え話を紹介すると… ある老人が、隣の空き地で、放課後に子供たちが毎日野球をするので、騒がしくて困っていました。 そこで老人は実に巧妙な計画を思いつきました。ある日、子供たちにこう言いました。 「君たちの野球を見るのがとても楽しくていつも家からみているんだよ、これからここで毎日野球をやってくれたら、100円あげよう」 遊びにきたのにお金がもらえるということで、子供たちはびっくりしましたが、その後一週間、老人は毎日100円をあげました。 翌週老人は「すまんがお金に余裕がなくなってきてね。これからは毎日50円にするけど、それでいいかね」といいました。 子供たちの一部はしぶ
ポータブルなWebアプリケーション - naoyaのはてなダイアリー
140文字で書ききれなかったのでブログに殴り書き。 Heroku のアプリケーションを人に渡す 昨日、「naoyaさんが作ってるiOSアプリのバックエンドサーバーに相乗りさせてもらえないか」という話をいただいた。自分でも同じようなAndroidアプリを作っているけど、サーバーサイドは作ってないからということらしい。 対して「githubにコードあるからgit cloneしてheroku pushすれば動くし、自分で heroku にデプロイしてよ」と応えた。相乗りしてもらってもよかったのだけど、こちらでコードを書き換えたりメンテしたときに先方のアプリが停止することを考えると同じコードベースでサーバーは自分で立ててもらう方が何かと良い。 対象になったソフトウェアは Heroku で動かしていたので、Heroku Ready な形、つまり、必要な外部パッケージの一覧やサーバーの起動手順なんかは
トランザクションは再利用の敵である
釣りっぽいタイトル。「RDBのトランザクションが絡むとアプリケーション側のプログラムが書きにくくなる」という話です。 もちろんですが、RDBのトランザクション機能は偉大であり、Webアプリケーションでも意識して使わなければならず、「トランザクションなんて使うな」と言いたいわけではありません。 合成できない関数 PHPで素のPDOから考えます。たとえば、以下の関数に問題はあるでしょうか？ <?php /* * 古いデータをアーカイブテーブルに移す関数のイメージ */ function moveDataToArchive(PDO $db) { $db->beginTransaction(); try { $db->exec(' INSERT INTO archives SELECT * FROM data WHERE published < CURRENT_DATE '); $db->exec
エンジニアが作るネットサービスのアイデアがしょぼいワケ【えふしん】 - エンジニアtype | 転職type
Twitterクライアント『モバツイ』開発者であり、2012年11月に想創社（version2）を設立した有名エンジニア・えふしん氏が、変化の激しいネットベンチャーやWeb業界の中で生き残っていくエンジニアの特徴を独自の視点で分析 藤川真一（えふしん） FA装置メーカー、Web制作のベンチャーを経て、2006年にpaperboy&co.へ。ショッピングモールサービスにプロデューサーとして携わるかたわら、2007年からモバイル端末向けのTwitterウェブサービス型クライアント『モバツイ』の開発・運営を個人で開始。2010年、想創社（現・マインドスコープ）を設立し、2012年4月30日まで代表取締役社長を務める。その後しばらくフリーランスエンジニアとして活躍し、2012年11月6日に想創社（version2）設立 若干釣り気味のタイトルですいません。今通っている大学院の授業で、漫画家の浦沢直
受託開発脳から自社開発脳へ切り替えの7つの壁
velc: これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1. 本
プログラミングは「名前」が9割。 - このブログは証明できない。
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは？」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
プログラマになろう - 日々常々
もうすぐ4月になると言う事で、時事ネタ。コの業界、特にエンタープライズなSIerやその協力会社なんかに就職される方向けに、夢や希望をなるべく潰さないつもりで書いてみる。 PGになってはいけない SIer用語でPGって言葉があります。あとSE、PL、PMとかありますけど、序盤は関係ありません。これらは契約形態は違うのですが、作業内容よりも主に単価で分けられます。で、PGは「末端作業員」と言う意味です。 PGはプログラマではありません。プログラマに失礼です。PGにプログラムは作れません。また、PGはコーダーでもありません。PGにコードは書けません。PGはSEの指示の元、似た事をしている既存システムのコードを切り貼りして、それっぽく動くものを作る下請け作業員でしかありません。そこに創造的な仕事は一切ありません。多くのPGは自らの意思か外部からの圧力によって、思考を放棄もしくは停止しています。PG
プログラマーが会社を辞める理由 - とあるプログラマの備忘録
僕は7月に転職した。 前にいた会社はそこそこの大きさ100人弱、一時期は「ベンチャー企業」として 成功をしようとしていたが、この不景気の波に大きく飲まれて会社は弱体化。 給料は通常通り支払われるものの、 役員クラス＆中堅がバシバシ抜けていく状態になっていた。 この状態になったのは僕が会社に入って3年目のことだったが、 別にこの状態になったから会社を退職したわけではない。 ではなぜ会社を退職したのか？ 「日本のプロジェクトは他会社からの寄せ集めで作成されることが多い！」 僕がかかわったプロジェクトは7つだったが、 自社での開発たったの1つ。 他は常駐開発という名の派遣だった、 最初は何も疑問を抱かなかったけど、これってなにがおもしろいの？ 常駐先で知り合いになれる人が良い人だったとかそんなことはおいておいて、 なんか会社が金額と見合ったプロジェクトを見つけてきて面接、 通ったら3カ月〜半年程
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
