  |
はてなキーワード: swiftとは
これ。
http://www.okamura.co.jp/product/desk_table/swift/
欲しい。
でも15万円もお金出したくないなぁ…。
一方 Autonomous の SmartDesk2 なら送料込みで8万円くらい。
https://www.autonomous.ai/smartdesk-sit-to-stand-height-adjustable-standing-desk
送料だけで3万5千円位するのが驚きだけどそれでも安い。
買おうかなぁ。でも
https://www.autonomous.ai/smartdesk-sit-to-stand-height-adjustable-standing-desk
とか見てると本国ですらサポート悪いことが見て取れてちょっと…。
オカムラがもっと安い電動の昇降式デスク売ってくれないかなぁ。
手動は嫌なのよねぇ。
年収の方は去年一昨年で3倍増したので、今年は今まで目を背けてきたことを頑張ろうと思う
※難易度低い順
・週1日は仕事せずちゃんと休む（遊ぶ）
・ヲタ活を再開する
・引っ越しする
・友達を作る
・新しい趣味を見つける
・海外旅行する
・彼女作る
去年一昨年の平均残業が1000時間超えてる身としては高すぎる目標で目眩がする
※順不同
・週末起業、今作ってるサービスの売上を建てて年末まで生き残る
・今の会社のプロダクトのグロース。DL数500万、MAU250万目指す
・アニヲタ向けのアプリをリリースする（今のサービスリリース後着手）
・swiftとKotlinにもっと慣れる （swift先行、Kotlinは今のサービスのA版作る時に教えてもらう）
・phpとRails、もう少し安定して書けるようになる（実務を通してだからこれは大丈夫）
まあいいや
がんばろう
買う目的以外にも、いま何が流行ってるのかを本の出版の流れから推測してるわけですよ
いやgoogleの検索とかQiitaとかgitHubとかほかにもいろんなところから流行りを推測するなんてあるけど
やっぱり本で勉強するのが一番だと思ってるおじさんからすると、本が出版される＝流行ってるってことだと思ってるからねいまだにｗ
それでみると今は明らかにpythonがキテるわけですよ
こりゃ本当にデータサイエンスが盛り上がってるんだろうなって感じ
そんで相変わらずのSwiftね。これはもうiPhone開発の必須だもんね。とくに日本じゃiPhoneだ
同じくらいunityがもりあがってるなってのは感じる
地味に本が出版されつづけてるJavascriptやPHPも存在感あるなって思いながら見てたんだけど
本が出版されないんだよね
4のときはすさまじい速さでキャッチアップして本が出版されたのにさ
もうみんな分かり切ってるから出版されないの？ネットで十分じゃい！みたいな
Rails界隈の人だれか知りませんかね
それとlaravelとか出版されないね。海外では人気です！っていうけど
ネットでやたらうるさかったフロントエンド界隈は全く本が出版されないね
ReactとかAngularとか
でもそれでいうならRails4のときの盛り上がりは何だったんだろうってくらいみんな一生懸命だったよね
だから5の無風感が怖いんだよね
http://anond.hatelabo.jp/20160902031012
はてブで批判してる人たちよりよほど志のある学生さんだと思うので、いろいろ書いてみます。おっさんのたわ言ではありますが、元記事の人にすこしでもヒントになればと思って。
まず、日本の大学で勉強しても実用的なソフトウェアが書けるようにはなりません。どういうことかというと、「情報系の大学に行けば○○が作れるようになる!」という世間一般の期待と、実際に大学で教えている内容には大きなギャップがあるということです。
これは大学が悪いのではなく、大学はそもそもそういうものであって、それが世間に認知されてないというだけです。
具体的に挙げてみましょう。
大学で教えてる内容ってこんな感じなので、ゲームやアプリやサービスを作ることが目的の人から見ると、役に立たない内容にしか見えませんし、実際たいして役に立ちません。その証拠に、大学の情報系学科を出ていないのにゲームやiOSアプリやWebサービスを作っている人はゴマンといるし、逆に日本の大学の先生でゲームやiOSアプリやWebサービスを作れる人はほとんどいません。
これは重要なことなのでもう一度書きますが、日本の大学の先生でゲームやアプリやサービスを作れる人はほとんどいません。大学の先生が得意なのは、プログラムを書くことではなく論文を書くことです。論文のためにプログラムを書くことはありますが、あくまでおまけです。
そのため、大学で勉強してもゲームやアプリやサービスが作れるようにはなりません。だって教えている側の先生が、ゲームやアプリやサービスを作ったこともなければ、作り方も知らないんだから。
そういう経験のない人たちばかりですよ、日本の大学の先生って。そんな人たちの授業を受けて、アプリやサービスが作れるようになると思うほうがおかしいでしょう。
ためしに、先生方のTwitterアカウント名でGithubを検索してみてください。いまどきGithubにアカウントがないとか、あったとしてもTestCaseすらないコードとか、そんなものばかりです。「研究内容をライバルに知られるわけにはいかないからGithubは使わない」という言い訳する人がいそう。けど、本当はGitが使えないだけでしょ？
あるいは、先生方の個人ページや研究室の紹介ページを開いて、HTMLソースを見てみてください。doctype宣言がないとか、viewportの指定がないとか、Pタグの中にULタグを使ってるとか、そんなのばかりです。HTMLすらろくに書けない人が、Webアプリを作れると思いますか？きっとXSSもCSRFも知らないですよ。
ですので、そういうことを勉強したいなら、ベンチャーやIT系企業に入るべきです。大学でそういうことを勉強しようとしても、教えられる人がいないから無理。
（「大学はそんなことを教える場所ではない！」と怒る人いると思うけど、教えられる先生がいないという事実をごまかすために怒ってるだけだから。）
とはいっても、大学の先生がプログラムがいっさい書けないというわけではないです。彼らが得意なのは、コンパイラやインタプリタやOSやソルバを作ることです。これらも実用的なソフトウェアと言えなくはありませんが、ゲームやアプリやサービスとはジャンルが大きく違います。
そのため、大学の情報系学科に進めばコンパイラやOSや機械学習ライブラリを書けるようにはなるかもしれませんが、それはゲームやアプリやサービスではないので、繰り返しになりますがそれらを作りたい人には大学は向きません。
じゃあ大学で授業を受けるのってムダなのかというと、必ずしもそうではないです。
大学で教えている内容って、ゲームやiOSアプリやWebサービスが一通り作れるようになってから、その先を目指すときになって初めて必要になることが多いです。たとえば、
こういうときになって、初めて大学で教わった内容が生きてきます。逆にいうと、そういう状況にならないと、大学で教わった内容は生きてこないと言えます。（情報系の学科で学んでいるなら、ライブラリや言語やOSを「使う人」ではなく「作る人」にぜひともなってほしいですね。）
元増田は、社会に役立つ実用的なソフトウェアを作りたいようです。しかし残念なことに、大学が教えている内容はその目的には合致していないことを説明しました。
こういう事情なので、元増田には大学をドロップアウトしてIT系の会社に入社することをお勧めします。ドロップアウトが難しいなら、インターンやバイトでなんとしても入り込むことです。
入るべき会社は、教育に力を入れている会社です。20人未満の小さな会社では教育に力を入れている余裕はないので、小さな会社はやめたほうがいいです。簡単にぐぐってみたところ、はてなやPixivやクックパッドやDeNAやドワンゴは教育制度が確立しているようです（違ってたらごめん）。そういった会社に入ったほうが、大学の授業を受けるよりも、元増田の目的にかなうのは間違いありません。
そして何年か働いて、iOSアプリやWebサービスが一通り作れるようになったら、大学に入り直すことです。これはとても効果的なので、元増田には強くお勧めします。
上で説明したように、大学というところは、ゲームやアプリやサービスの作り方は教えてくれず、それらが作れるようになって初めて役に立つことを教えてくれます。そのため、元増田はIT系の会社に入ってアプリやサービスの作り方を勉強し、それらが作れるようになってから再度大学の門をたたくのが、いちばん効率的です。
なお繰り返しますが、入るべき会社は「教育に力を入れている会社」です。今のIT系企業では、インターン生を「格安で使えるバイト君」としか見なしていない会社が多すぎます。そういう会社は、コストが掛かることはいやがるので、教育もろくにはしてくれません。逆に教育に力を入れている会社では、インターン制度を「将来の戦力を選別する期間」と見なしています。
残念ながら、そういう会社は東京に集中しているようです。例外は京都のはてなくらいでしょうか。地方の大学生にとってはつらい現実なので、はてなやPixivやドワンゴは地方でのインターン開催をお願いします。あとレベル5は九大と九工大の学生を鍛えてあげてください。
余談ですが、学生さんにひとこと：
インターンやバイトで潜り込む先の会社を選ぶときは、就活と同じような時間をかけて選んでください。バイトだからとかインターンだからという軽い気持ちで会社を選ぶ大学生が多いから、それを食い物にしている悪質経営者があとを立ちません。インターン生が「格安の学生バイト」として使われている現状を是正するために、学生のほうでも注意してください。
ドロップアウトを進めた手前、書こうと思ったけど、長すぎるのでやめた。
リツイートが100超えたら書く。
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリを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以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
追加
http://raf00.hateblo.jp/entry/2016/07/26/011858
アップスタンドも持ち歩かない戯けは、ロードに乗るな触るな、関わるな。迷惑だから消えろ
http://d.hatena.ne.jp/kanose/20160720/roadbike_stand
http://goldhead.hatenablog.com/entry/2016/07/21/225736
http://anond.hatelabo.jp/20160721222328
弱ペダオタとか、最近、漫画から入ってきたローディは意外と行儀がいいんだが
このブログみたいに、
お前ら貧乏人に買えない高級車が壊れたら弁償してくれんの？ｗ
そんな金を稼げるオレサマが怪我したら保障してくれんの？ｗ
はっきり言って、馬鹿なので消えて欲しい。
たかが数か月、ロードバイクにまたがった程度で知ったかぶってんじゃねぇよｗ
ロードバイクには、フレームに取り付けなくてもいいスタンドが沢山あるし
それらはたいして高くもないし、重くもない。アップスタンドに至っては60gと軽い。
お前らのブクブクと太ったみっともない腹の脂肪の一つまみにもならないっての。
レースに出るでもなく、町中でのるのであれば、60gが邪魔になるなんて事があるはずがない。
ついでに言っとくと、ホイールや機材に手をだして1㎏を削る位なら、1㎏脂肪を減らせ豚
1㎝乗車姿勢を低くしろ、10Wでもより強く出力する筋力をつけろ無能
スタンドを付けたくない？
ホイールや二台目を買う位なら、パワーメーターやローラー台を買えアホｗ
しまなみ海道とか、ロードバイクを誘致したいサイクリングロード周辺では、ロードバイクを室内に持ち込んでもいい宿や
空気入れとか水の補給とかまでさせてくれる店が普通にあるし、あちこちにラックもある訳だが、それは周辺経済への影響を期待されてのことでWInWin
だから、道路を走る事も住民の理解がある程度は得られているし気持ちよく走れる。
だが、普通に都内のラックを常設してもローディ以外の得にならん。なくて当たり前だ。
言うなれば、我々のロードバイクは、他の歩行者や自動車などにお目こぼししてもらって走らせてもらって
時には一時的に路上駐車させてもらってる立場で、これからその権利を認めて欲しいと思ってる立場でもある。
まして、トラックが仕事をしてる国道の峠道とかを、自称「坂バカ（笑）」が登るとか恥を知れと言いたい。
つう訳だから
当たり前の様に何時間も路上のガードレールに地球ロックで駐輪したり
そんな行為は、以ての外だ。
事故って二度と乗れないほどの怪我を負え
ロードバイクすててマラソンしてろ、フルームですら山を走ってんぞ
いろいろ試して見た。
ゲーム実況 0円
ブログ アフィ 300円
まずは、毎日続けることが大切だと思ったけど、面倒くさくてやめた。
作ろうと思うたびにxcode のバージョンが上がったりswift導入されたり
と学びなおしやった。
enchant.jsなんてのもあったかな。
Scratchでなのぼーど動かしてみたり。
一番売り上げが立ったのは、畑借りて農業の真似事してたときやった。
もうやめたけど。
今は、dmm3dのクリエターズマーケットしようと企んでるけど、
試したら思ったより高くて、断念しそう。
あとは、rubyをやってみようと、技術書を買おうかアマゾンとにらめっこしてる。
頑張ってください。
一番役に立つってるのは、excelvbaです。
先ずどの環境で作るかを考える。
AndroidならJava、iOSならSwift、ブラウザならJavaScript、MacやWindowsもある。
どれにしても習得するのはそこそこ難しい。
難しい。頂点シェーダー・フラグメントシェーダーも書く必要がある。
AndroidやiOSのライブラリに余りいいものはないかもしれない。
WebGLならThree.jsがメジャー（シェーダーも自分で書かなくてもいい）。もっと小さいライブラリもある。
JavaScriptプログラムをAndroidやiOSやパソコンで動かす事もできる。
勉強している内にUnityを使ったほうがいいかなとか色々思うだろう。
そうで無くても、GUIプログラミングは全てが一つのプログラムに入り複雑。
ここまで認識するようになるのに1年ほどかかるだろう。
（何か環境を一つに決めて初心者用の本の通りにすれば短期間でできるが。）
処理ごとにファイル出力して（メモリより時間がかかるが）分離しやすい場合も多い。
Rなどでのプログラムも案外手軽にできる。
コマンドプログラムでGUIを使うのは色々な方法が有る。Javaなら問題ない。
