はてなキーワード: overflowとは
レプテーション機能？すまん後で調べてみる
stack overflowは一個の形だな、でも似たことしてうまくいってないサービスもあるから解せない。何か足りないのか
他業界で似たことできてるとこが少ないから、汎用的かどうかは判らんが
これは情報収集で同じことが言える。自分に有益な情報のアンテナを張ると言うのは非常に難しい。この時代においても抜けおちてる領域だと思う。
この領域が抜けてるうちは「経験豊富なベテラン」の優位性は揺るがないが、代わりに人間が次のステージにいけない気がする
例えばベテランフルスタックな人間なんてのはほぼ存在し得ない（存在しない方が雇用は安定しそうだけど）
元増
吾輩は無職である。職はまだ無い。どこで無職になったか、とんと見当けんとうがつかぬ。
何でも薄暗いじめじめした所で手斧を投げられていた事だけは記憶している。
しかもあとで聞くとそれは増田という人間中で一番獰悪な種族であったそうだ。
・・・・
まぁ、前置きの冗談はこの辺までとして、前々から作りたいな思っていた
Webサービスを中々時間が取れず作るのを諦めていたのだけど、
僕自身、プログラミングを生業とする職業では無く、学生時代も特にプログラミングついて何か
始めたのが昨年末の大晦日ちょい前なので、約5ヶ月掛かり、当初想定していた期間より
かなりの時間が掛かってしまい、反省点等含めその辺の事を書けたらなと思います。
■やりたい事（実装した事）
・ゲームユーザー同士を繋げるマッチングサイト（出会い系ではないよ。）
・タグをつける
構成を書いた方が良いと思うので
以下になります。
■構成
--------------------------------------------
FW：Flask 1.0.2
ORM：SQLAlchemy 1.2.7
その他ツール等：Let's Encrypt/fail2ban/等々
--------------------------------------------
ほぼ、既存のベーシックなサーバーサイド側の制御のみです。（jsで非同期通信はしてます）
変えるのもなと思い、取り敢えず上記です。
■選定理由
Railsの名前を良く聞くのでRuby on Rails触ったのですが、
Railsには馴染めなかった（扱えなかった）ので
何かマイクロFWの方が良いのだろうと、Sinatraいこうか思いましたが
Railsの印象が強く残った為、Rubyは止めてPythonに移りました。
今度は初っ端からマイクロFWが良いだろうとFlaskのサンプルを試すと
比較的プログラミング初学者でも扱いやすく覚える事も少ないので、PythonとFlask
の組み合わせで決定。
（気軽にプログラムを書け、自分がイメージしている処理や制御を素直に実現できる点が
書いていて気持ちが良いです。まぁ分からない所も有りますが、そう思わせてくれる点
が良いです。モチベーション的に）
NginxとuWSGIの組み合わせはFlaskで検索すると一番でてくるのでこれに決定。
SQLite3 はマイクロFWだから軽めのDBでたぶん大丈夫だと思ったのでこれに決定
■開発概要
・まずPythonの開発環境を整えようとなり、WindowsにVagrantをインストールして
仮想マシンの環境構築。ゲストOSの中にPyenv等を入れPython環境構築
・上記構築後に取り敢えず小さなサンプルから作ろうとなり、簡単なCRUDをFlaskで行える様にしました。
これができた時は嬉しかったです
・上記が出来てから、本番の開発に移りCRUDをベースにひたすら肉付けていく
→ユーザー登録機能作成/ログイン機能作成/ユーザー情報表示/編集機能/チケット作成/及び編集/バリデーション
・細かいViewの調整とスマホ用のViewも作成（レスポンシブルでは無いので）
・本番用のさくらVPSに環境構築とセキュリティ用のツール導入とLet's Encryptでhttps化
■悩んだ点/反省点
・悩んだのがタグ機能周りになるとどうすればよいか、かなり悩みました。
結論を言うとToxi法を使用しましたのですがここにたどり着き、理解するのに結構時間がとられました。
また、実装したらしたで、今度はそのタグ機能を検索するとなると検索ワードが1つとは限らないので
クエリーを動的に生成する必要が有り、これも実装するのにかなり時間が掛かりました。
SQL文だけならば比較的すぐに検索でヒットしますが、それをSQLAlchemyでどう実現すれば良いか分からず
かなり時間が掛かりました。DB設計やSQLAlchemyの文法に自信は無いですねぇ。。
・1次情報のリファレンスからは情報得ることがほとんど出来ず（たまにはできたが）、
Stack OverflowとQiitaと個人ブログが無ければこのサイトできなかったので
■総評
・5ヶ月と時間が掛かりまた反省点も多々有るが、とりあえずサービス公開まで
もっていけた事が嬉しいです。ただただ嬉しい。
・FlaskとSQLAlchemyの情報が日本語が少ないので公式リファレンスとStack Overflowを
行ったり来たりしたおかげで英語アレルギーがそこまで無くなった。
■成果物
オンラインゲーマー向け（e-sports）のマッチングサイトになります。
名前が安直で小学生が5秒で考えたような名前ですが、安直で気に入っています。
作った理由は、僕はBF1が好きなのでオペレーションキャンペーンと言うモードを
やろうとしたのですが、時間帯が悪いのか過疎なか分からないが全然マッチングしないのですよ。
やりたいのにマッチングしないので出来ないどうしよう、と。
また、昔セールでFarCry3をかなり昔に購入した時（既に4が発売済み）にCO-OPモードが全然マッチしない事が有り
旬が過ぎたオンラインゲームは中々マッチしなくてほぼシングルモードしか出来ない事は割とあると思うんです。
今だとBF4もかなり人数がいない状態なので特定マップのみとか。
なのでオンラインゲームでマルチプレイやCo-opで人を集めたい時、PUBGやFORTNITE等バトロワゲームのスクワッドを
募集する時、オンラインゲームの大会（e-sports）を開きたい時に利用して貰えると嬉しいです。
主に想定ユーザーと考えているのは、FPS/TPS/RTS/MOBA等のPCゲーマーをメインに考えていますがCS機やTCGでも
使って貰えると嬉しいです。
あとViewがレスポンシブでは無く、PC用とスマホ用しかなくタブレット用の中サイズのViewが無いのでご了承下さい。
遊んでも良いよという奇特な方がいましたら当該サイト内でコメント頂けると幸いです
・BF1（PC版）
それでは長々とありがとうございました。
・・・・
日月を切り落し、天地を粉韲して不可思議の無職に入る。吾輩は死ぬ。
ありがたいありがたい。
公式HPではそこで書いたことが全て公式の発言になってしまうことから、
「こうやって作るべき」といった公式の中でも意見が分かれる議論には言及できず、
どうしても事実だけを淡々とまとめるリファレンスのような内容に偏ったりと、
（どちらかというと公式より同じ利用側の立場から教えてもらえる書籍の方が入りやすい）
それ以外のネットの誰が書いてるかわからない無料の情報は間違ってる場合も多い。
ネットの仕組み上、正確な情報より、読み手が面白いと思ったものが
Stack Overflow レベルになると間違いは少ないとは思うけど、
日本の Qiita とかで話題になってる技術記事はひどい内容のをよく見かけるね。
（反論してる人が少ないのは読み手が間違いに気づいてないのか、批判は失礼だと思ってるのか）
一方、書籍はその分野である程度評価されている人しか出版の話にならないので
最低限の内容の正確性は保証されていたり、
そもそも金を取るので読みやすさとかに配慮されていることが多い。
また書籍一冊分の分量からしても技術の全体像が体系化されて説明されるので
まぁ、最新情報が手に入りにくかったり、読者の最大公約数を取るので
高度やマニアックな内容に触れにくかったりという側面はあるね。
要は、それぞれ一長一短あるんだから、賢く使い分けるのがよいと思う。
俺からしたら、両方のいいとこ取りをすればいいのに、
Stack Overflow
Server Fault
Super User
Web Applications
Webmasters
Game Development
Software Engineering
WordPress Development
Geographic Information Systems
Electrical Engineering
Android Enthusiasts
Information Security
Database Administrators
Drupal Answers
User Experience
ExpressionEngine® Answers
Cryptography
Code Review
Magento
Programming Puzzles & Code Golf
more (7)
Photography
Graphic Design
Seasoned Advice (cooking)
Home Improvement
Academia
more (8)
Skeptics
Mi Yodeya (Judaism)
Travel
Christianity
English Language Learners
Arqade (gaming)
Bicycles
Role-playing Games
Motor Vehicle Maintenance & Repair
MathOverflow
Mathematics
Cross Validated (stats)
Theoretical Computer Science
Physics
Biology
Philosophy
more (3)
Meta Stack Exchange
Stack Apps
Area 51
Stack Overflow Talent
この記事は「転職（その２） Advent Calendar 2016」12日目のポエムです。
こんにちは。プログラマーをしていた akiraak です。今はサンフランシスコで英語の勉強ばかりやってるので、プログラマーではくイングリッシャーになってしまいました。
さて、転職は多くの人が知っているように大変です。しかし、海外企業への転職はもっと大変です。さらに、家も就職先も決まっていないのに海外に移住してしまうというのはどれだけ無謀な行動なのでしょうか。今回の記事の内容は、妻である ento がまさにそのような状態でシリコンバレーに移住し、そこで仕事を得るまでの1ヶ月半ほどのログになります。この無謀すぎる人間のログをお楽しみください。
2014年10月にベイエリアをakiraakと下見し、フィーリングが合うことを確認
2015年3/31 両親と久しぶりに会い、出生証明書と期限切れUSパスポートをもらう
4/26 USパスポート申請予約 (最初は5月17日で予約したが、キャンセルが出ないかカレンダーを見張った末、5月12日で予約できた)
5/?? 「entoとポッキーが先行引っ越しするのはありだよね」とakiraakと合意し、資金面で問題ないかを後で検討することに
5/11 MindMeisterで引っ越し関連作業をまとめるマインドマップを作る
5/12 USパスポート申請: 犬を連れていく関係上、できれば5月中に渡米したいのでなるべく早く用意してほしいとお願いする
5/13 同上
5/15 Googleスプレッドシートでお金の計算をし、アメリカにポッキーと先行引っ越しすることを決める
5/17 Sky Toursで飛行機チケット予約 (往復便をうまく使ったりなどして、片道便をお安く予約してもらえた)
5/18 completeapp.comにユーザー登録、その後随時todoにコメントをもらう (AngelListでみかけたスタートアップ)
5/18 自転車の運び方について製造元にメールで問い合わせ、返信をもらう
5/21 HanaCellにSIMカードを注文
5/21 USパスポート発送の連絡がくる
5/21 6月に泊まるAirbnbの予約に失敗 (Airbnb以外のサイト経由で別の人が既に予約していた)
5/22 LORO日本橋に適切なサイズの箱の有無を電話で問い合わせ、用意してもらう約束をする
5/24 RoomieMatch.comとroommates.comとroomster.comに登録、Redditにルームメイト/部屋募集を投稿
5/26 akiraak実家で晩ご飯をいただき、地元の友達が大事だとさとされる
5/27 USパスポート到着
6/05 飛行機搭乗
6/06 組み立てた自転車をLaurel Cycleryにメンテに出す
6/06 近所のスーパーマーケットのレジで「昨日引っ越したばっかりで、仕事を探してるんだ」と言ったら、「この前うちでジョブフェアをやってたんだけどね」と教えてもらった
6/06 TTGL見始める (Redditで会話したイギリスの大学院生のおすすめ)
6/08 RoomieMatch.comのプロフィールを更新 (2人用から1人用へ)
6/08 Creddle.ioにレジュメをアップし、Redditの校正スレに投げる
6/09 RoomieMatch.comでマッチングされたルームメイトから電話がかかってきて、部屋を見に行く約束をした
6/09 同じ家のAirbnbゲストにくっついてSF見物 (彼女も仕事を探していて、SFのMacy'sにスーツを買いに行った)
6/09 Whitetruffleに登録
6/09 Hired.comからプログラミングの問題を解いたら翌週の「オークション」に掲載するよ、と連絡がくるが、なかなか手がつかず最後までスルー
6/10 AngelList、Hacker Newsの「Who is hiring this month?」スレからめぼしい応募候補をリストアップ、Glassdoorでレビューを確認 (以下の記事を参考に、Google スプレッドシートにまとめていった http://robertheaton.com/2014/03/07/lessons-from-a-silicon-valley-job-search/ )
6/11 Soylentに発送先を連絡
6/12 AngelListで何社か応募、リモートOKのところを優先する
6/12 Underdog.ioから翌週にプロフィールを掲載するよと連絡
6/13 借りる部屋を3箇所内見し、仮決め: 家賃はAngelListに掲載されているエンジニアの平均年俸の40分の1を目安にした
6/15 借りる部屋を本決め
6/15 Underdog.io経由でB社から連絡
6/15 銀行口座開設を試みる (住所証明がなくてダメ、その足で自分宛の郵便を速達で送った)
6/15 Airbnbのホストさんがリクルーターを紹介してくれる
6/16 銀行口座開設を試みる (ソーシャルセキュリティカードがなくてダメ)
6/16 さらに応募 (C社含む)
6/16 Soylent到着
6/17 アスペの集まりに参加: 晩ご飯を一緒に食べる会 (「仕事を探してるんだ」と言ったら、「うちはいつも仕事を募集してるよ」と医療機器関係の会社を紹介してもらい、レジュメ校正ビジネスを始めたいという技術ライターさんに「無料で校正してあげる」と連絡先を教えてもらった)
6/18 C社とGoogle Hangoutミーティング (この時点でここに入る腹積もりをしたと思う)
6/21 TTGL見終わり
6/24 C社と対面面接 (6.5時間: エンジニア計3人とペアプロなど + みんなでランチ + 社長面接)
6/24 身元照会先を依頼、連絡
6/25 Lyftのタダ乗りクーポンでの帰り道、ドライバーさんに「仕事を探してるんだ」と言ったら、元奥さんがそれ系の仕事をしてるからと紹介してもらう
6/27 同上
6/28 同上
応募候補をまとめたスプレッドシートには、先方からの打診を含め、結局79個の会社をメモった。応募したのは14社で、何らかのリアクションがあったのは4社。大半はAngelList上でしか応募していないので、メールで直に応募すれば反応率は上がるかもしれない。職探しサイトでプロフィール登録したり応募したりする度に、レジュメの内容や言い回しをブラッシュアップしていくことができたことは、よかったと思う。
上で挙げた数社を含め、会社側から打診をうけた件数は以下の通り:
Whitetruffle: 11件
AngelList: 7件
Stack Overflow Careers: 1件 (リクルーターからはさらに1件)
Underdog.io: 1件
ホワイトボードでアルゴリズムの問題を解く系の面接の予習は、やろうと思いながら結局ほとんど何もしなかった。やったのは、過去のプロジェクトでやったこと・学んだこと・つらかったことなどの振り返りと、レジュメを書く中での自己内省。
ここまでは ento お引っ越しでした。僕はというとビザがないので日本でお仕事をしていました。そして2015年7月に渡米して結婚。10月に弁護士経由で配偶者ビザの申請。2016年7月に発行されたので8月にアメリカにお引っ越し。10月にグリーンカードも発行されて今に至ります。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
バイオ系は、つぶしが効かない。ポイントは、そうなんですよね…。
確かに主成分分析、流行りの統計的手法をなどを良くわかろうとするならば、線形代数とか知っている格段に良さそうですよね。
もしかして、普段から結構レベル高い人を相手に、されていますか。旧帝大系か、早慶レベルの人ですか。というか、アカデミックな仕事を得ようとするならば、当然ですかね…。
---
プログラミングといっても、csv file のサイズも、せいぜいExcelで開くことが出来る程度の量のデータです。
多くても5000行もありません。
でも、Rでloopで回して、ggplotでグラフを描く、optionを変更とかは、しています。
pythonは、プログラマーの人にも、手伝って貰って、csvから、matplotlibを使ってなんとか、望んだ形のグラフを書ける程度です。
（Learn python hard way なるものを途中で挫折のレベルです。）
業務で、それらのR, pythonの技術を使える環境にあるので、学んだほうが、自分の為にも、職場の人の為にも、なりそうですね。
プログラミングを書けるようになるには、Stack OverFlowとか、英語のドキュメントを読めるとやっぱり、違いますよね。
英語が出来る外国人っていいなぁって思います。もちろん、日本人でも。
—
はてなで、ブックマークがたくさんついていたので、あの記事も読みました。
「圧倒的に生産性の高い人（サイエンティスト）の研究スタイル、
http://d.hatena.ne.jp/kaz_ataka/20081018/1224287687」
経験が浅いうちは、経験のある人とのディスカッションやコールドインタビューという手法が大切、ということを思い出しました。
+++
はてなー技術的な動向としては、データサイエンスって流れみたいですね。
細分化が激しそうですね。
機械学習は、たとえば、slide shareで、パターン認識と機械学習入門
http://www.slideshare.net/mmktakahashi/ss-13694313
オライリー本の「入門 機械学習」Rで、書くやつです、これは、買いました。
そういうことならば、道としては、間違ってなさそうですね。
自分の興味で食べていけそうな感じも、ないわけではないですね。
--
ーーー
| サイト | 登録 | ログイン | 備考 |
|---|---|---|---|
| IPA 独立行政法人 情報処理推進機構：情報処理技術者試験 | × | - | |
| SHARP i CLUB | × | - | |
| ケンタッキーフライドチキン | ○ | × | |
| Qiita - プログラマの技術情報共有サービス | × | - | |
| jsdo.it - Share JavaScript, HTML5 and CSS | × | - | |
| 関西電力 | × | - |
| サイト | 登録 | ログイン | 備考 |
|---|---|---|---|
| ○ | ○ | ||
| 楽天市場 | ○ | ○ | |
| Stack Overflow | ○ | ○ | |
| ITプログラマー・エンジニア転職のpaiza | ○ | ○ | |
| マイ大阪ガス | ○ | ？ | 未検証 |
| 三菱東京ＵＦＪダイレクト | 三菱東京ＵＦＪ銀行 | ○ | ○ | |
| クロネコメンバーズ | ○ | ○ | |
| 佐川急便 - 【Ｗｅｂサービス】 | ○ | ○ | |
| サンケイリビング新聞社 | ○ | ○ | |
| 宅配ピザのドミノ・ピザ | ○ | ○ | |
| ＥＴＣ利用照会サービス | ○ | ○ |
aはまだ読んでない値のリスト、bは既に読んだ値のリスト、totalは読んだ値の総和を意味している。
f(xs, b+x, total+x)と再帰的にa,b,totalを更新していけば、一個ずつリストを読んでいくことができる。
後はf(randoms, [], 0)を呼んで、totalが50を超えたらbを返すようにすればいい。
まあこんなん実質変数使ってるみたいなもんじゃねえか、というハナシではあるけど。
関数型のメリットはパーツの再利用がやりやすいというところにつきると個人的には思う。
たとえばこれの応用として、総和が50を超えたらじゃなくて総和が素数になったら総和を返すような関数f2を作れと言われたら？
コピペしてif文の中だけ変える？
……手続き型の発想だけだとそうするしかないかもしれないけど、
関数型言語なら、fにcheckという引数を追加して、check(total)がtrueならbを返すようにすれば簡単にf2やf3を作ることができる。
ラムダ式を使って、条件を判定する関数をその場でポンと作ってfに与えることもできる。（今はJavaとかC++もラムダ式使えるね）
再帰があんまり深くなりすぎるとStack Overflowになってしまったり、速度がどうしても犠牲になりがちだったり、
もちろん向き不向きはあると思うけど、関数型便利ですよと、そういう話でよかった？
http://anond.hatelabo.jp/20131008141912
全く困らない。慣れる。
適切な単語の選択のセンスはプログラミング経験でいくらでも身に付くので、
辞書があれば困らない。
エラーメッセージで検索するとよくStack Overflowなどが引っ掛かるが
ある程度長い場合は機械翻訳に突っ込むこともあるが意味が取れなかったことはない。
質問をしたことは無いが、コードとエラーメッセージを簡単にまとめればなんとかなると思っている。
あまり気の利いたことは書けない。
Issueを要約したタイトルぐらいなら書ける。
内容をすべて英語で書こうとすると日本語の時の数倍の時間が掛かることになるため、できれば書きたくない。
僕はプログラマーです。
でも僕のMacBookProには何故かAdobeのソフトウェアが入っています。
デザイナーの人がデザインファイルを.psdや.aiや.fw.pngのまま当然の様に投げて来るからです。
僕はAdobeのソフトウェアに精通しているわけではありません。
ですので複雑なレイヤー構造のファイルを切り出すのにはかなり時間を要します。
でもレイヤー構造の説明をしてくれるデザイナーの人は殆ど居ません。
デザイナー同士だとその複雑な構造でもやり取り出来るのかも知れませんが、僕には大抵よく分かりません。
例えば、Photoshopのエフェクトレイヤーが掛かっているボタンはボタンだけ切り出す時に凄く苦労します。
例えば、薄くシャドーが掛かってるデザインは素敵な質感を表現出来るかもしれませんが説明してもらわないとどこまで切り出したら良いか分かりません。
一所懸命頑張って切り出した画像でアプリを作っていたら「この部分が滲んでいる」とか「ここが1pxズレている」とか言われます。
僕はAdobeに精通する為の努力をしなきゃいけないのでしょうか？
そもそもAdobeのソフトウェアは高価です。 今なら毎月3000円払わなきゃいけません。
でも実際使う機会は月に2〜3回あるか無いかです。
一回の起動が1000円です。
じゃあデザイナーの人にも僕がソースコードのまま投げても良いのでしょうか？
Xcodeは無料です。 AppleのiOS Developerライセンスは年8400円です。
ビルドから実機へのインストールくらいならボタン押すだけで出来ます。
じゃあデザイナーの人にもGitでデザインファイルを共有して貰っても良いのでしょうか？
Gitは無料です。 レポジトリは僕が作ります。 GUIクライアントは有料かもしれません。
多少学習コストは掛かりますがcommitとpullとpushくらいならすぐ覚えられます。
デザイナーの人が数分で切り出せるボタンを試行錯誤して30分掛けて切り出す間、僕がコードを書けばデザイナーの人が8時間プログラムを書くよりも随分作業が進む自信はあります。
きっと何かしらのデザインルールでレイアウトされたデザインの座標を一個一個調べながらボタンを配置していく間、僕がコードを書くよりも、最初からこのボタンはここに配置するってレイアウト図を見せてくれればバグを一個や二個くらい潰せる時間が作れます。
デザインファイルを最初からpngで書き出して貰ってレイアウト図と一緒にくださいというのはプログラマーの怠慢でしょうか？
どう書き出すとプログラマーが使い易いか一番良いのか分からない、とよく言われます。
でも、最初に言ってくれればどういう風に切り出して欲しいか説明します。
もしかするとアニメーションを追加する為にレイヤーにしたり、書き出す構造が変化することもあるかもしれません。
それでも僕がどこまで切り出せば良いか分からないシャドーを書き出した方が良いのでしょうか？
AdobeのツールはGUIだから誰でも分かるのかもしれませんが、それはデザイナーの人が
self = [super init];
if(self) {
[self setShadowImage:[UIImage imageWithNamed:@"shadow。png"]];
}
return self;
別に上の謎の文字列だって適当な文字列じゃないんです。 きちんとした意味があります。 誰だってちゃんと分かるはずです。
ボタンが1px右が正解か2px左が正解かを判別するよりも簡単に間違ってるかどうか分かるシンプルなものです。
確かにAdobeのツールはよく出来ているので僕でも頑張れば使うことが出来ます。
でも、僕はAdobeのツールを使った時の生産性よりも、Stack OverflowやはてなダイアリーやClass Referenceと睨めっこしながらキーボードを叩いて居る方が生産性が高い人種だと思っています。
ただ、デザイナーの人がもう一手間かけて頂けるだけで、僕はもっとコードを書いたりデバッグ出来るし、結果的にプロジェクトとして良い物が出来上がるんじゃないかなというだけなんです。
デザイナーの人がAdobeのツールを習得するためにマウスやペンタブを触っていた時間を僕はプログラムを覚えるためにキーボードを叩き続けていたんです。
もし、デザイナーの人がもう一手間かけて頂けたら...
元ネタ http://anond.hatelabo.jp/20120321162723
( http://anond.pha11.info/archives/9491 )