「フレームワーク」を含む日記 RSS

はてなキーワード: フレームワークとは

2019-03-26

anond:20190326095322

シングルトンって普通に使わないかなあ

頻繁には使わないけど

デザパタ手段で道具であって、目的と入れ替わるとおかしくなるけど

から、昔みたいに全部のパターンを覚えなければ駄目なんじゃないか、みたいな風潮は嫌いだけど、こういうときファクトリメソッドだよね、みたいなのは使用している言語フレームワークルールにもよるわけで、別にまったく無駄になった訳じゃないというか

デザパタなんて無駄ものだったんだよ、みたいな意見には賛同できないけど、意識しすぎるのもおかし

デザパタ結果論なのだから

2019-03-13

http://jinjor-labo.hatenablog.com/entry/2019/03/13/084116

cssフレームワークcss一切かかずに作れるようなすごく単純な数時間で作れるものをそれっぽく整えてみせるときだけ使うなー

そこそこの規模になると一から自作

2019-03-06

派遣プログラマ認証機能作らせたら

usersテーブルをfindAllして全部取得した後に

入力したID/passと一致するかどうかでやってやがった

プルリクエスト出してきたんだけどこれでマージされると思ってんのか??

いやこれ明日マジでどうしよう?

PHPのLaravelってフレームワーク使ってるからその通りに作ればいいのに

いったい何を考えてこいつこんなの作ってきたんだ??

単価80万だしてんだけどありえないだろ

明らかに不良品から返品して新しい人入れてくれないか

本当に派遣プログラマ使えないわ

プログラマだけど技術自体は好きじゃない

プログラマとして働くようになってそろそろ5年になるが、正直周りについていけない。自分自分自身にとって面白いもの、または世間一般の人にウケるものが作りたいのであって、技術自体はそんなに好きではないのだと最近気付いた。

いま旬とされている技術の大半は自分にとってはどうでもいい。最初はある技術面白いと思って、それを使った製品を作りたくてこの業界に入ったのだけれど、そのほかの大体の技術はどうでもいいんだよな。次々いろんなガジェットサンプルコードを試して一通り動かして楽しんでいる人がいるが理解できない…。

興味ある技術を扱うにしても、開発するにあたって使用するフレームワークライブラリ、開発環境などの細かい違いもどうでもいい。「こっちのがコードが綺麗になるから」とか…どうでもいいんだよな。いや、どうでも良くないのはわかるんだが学習コストを考えると気が重い。自分はそこにモチベーションはないのだが周りが嬉々としてそれらについて語ってる場に入っていけない。

なんていうか、プログラマから技術全体に興味があると思われているのを重荷に感じている。職種自分の興味にギャップがあるんだろうか。

2019-02-21

天空の城はてな '19

会長、ここは一体……?」

はてなの中枢だ。

 上の社屋などガラクタにすぎん。はてな技術は、全てここに結晶しているのだ。

 お前たちはここで待て。ここから先は役員しか入れない聖域なのだ

 

「なんだこれは?!

 互助会がこんなところまで…… 一段落したら全て焼き払ってやる!!」

「おおお……見たまえ。この巨大なサーバラックを。

 これこそ、はてなの力の根源なのだ

 素晴らしい。上場するまでの間、会長の帰りを待っていたのだ!」

言葉を慎みたまえ。君ははてな会長の前にいるのだ。

 これから会社上場を祝って、諸君はてなの力を見せてやろうと思ってね……

 見せてあげよう。はてな株券を!」

 

どぎゃーん

 

「ふはっはっはっはっ……素晴らしい。

 最高のショウだと思わんかね?

 見ろぉ! 株価ゴミのようだ!!!!」

「何をする!

 くそぉ……返したまえ……いい子だから。さあ!

 ……はっはっはっ、どこへ行こうというのかね?」

 

「そのCookie大事に持ってろ! 元CTO動画と引き替えだ!」

 

「立て! 鬼ごっこは終わりだ!

 ……終点データセンターとは、上出来じゃないか。こっちへこい!」

「これがデータセンターですって?

 ここは はてラボ よ。

 株価が滅びたのに増田だけ生きてるなんて滑稽だわ。

 あなた管理者IDは渡さない!

 

 はてなダイアリーがなぜ滅びたのか、私よくわかるの。

 シリコンの谷の歌にあるもの

 

 “烏丸御池に根をおろし、風と共に生きよう。

  サーバラックと共に冬を越え、犬とともに鴨川を走ろう”

 

 どんな素晴らしい理想を掲げても

 上から目線ブックマーカーたちをあやつっても

 京都を離れては生きられないのよ!」

Perlは滅びぬ。何度でも甦るさ

 はてなフレームワークこそ人類の夢だからだ!!」

「落ち着いてよく聞くんだ。

 ……滅びるサービスを教えて。ぼくも一緒に言う」

「えっ……」

「ぼくの左手に、手を乗せて……」

 ……

時間だ!答えを聞こう!!」

「「ハイク!」」

 

 

 

2019-02-20

オンラインエロゲ終了でオフラインプレイヤーを書いたら感動した

「対魔忍アサギ 決戦アリーナ」というオンラインゲーム(エロゲ)が終了する

まあ終了自体は仕方ない。このゲームゲームと言うには余りに大きな設計ミスを抱えすぎており、また、システム的にもかなり古くなっている。

だいぶ前からオンラインゲーム終了時にどうするか、という話はあるけど、あまり進展はない(ソシャゲ、ネトゲ等のサービス終了後のゲームの保存について考える、とか、米国でサービス終了オンラインゲームを著作権法例外とする動き―ESAは反対とか)。一つ根本的な問題として、本当にオンライン重要ゲームオフラインモードに余り意味がないのも大きい。

でも、対象エロゲ特に抜きゲ)なら話は別

何せ、最低限エロシーンだけ再生出来れば需要を満たす。

逆に、ゲームとしてのサービスが終わろうが俺には見たいエロシーンがあるんだよ!

anond:20190209083051 とかでも書かれていたけど、エロの質はいいし、ここにしかないものも多い。しかもそれは(ゲーム上で)自分が苦労して手に入れたものだ。勝手に閉じてほしくない。

……けど、運営コストを考えたらそうも言ってられないのはよく分かる。

というわけで、今こそオフラインプレイヤーの出番だ。

自分入手した分のデータダウンロードして、後は各人がローカルPC再生すればいい。

必要機能は大きく分けて、サーバからデータダウンロードしてくる部分、それからデータカードエロシーン)を閲覧するパートだ。

ちなみにこのゲームは初期に作られただけあって(?)、エロシーンに機能が少なく、BGV はおろか BGM も無い。オーバレイも1枚のみで、基本的に背景(シーン画像含む)と、テキストに 1:1 対応するボイスしかない。

これなら割とできそうな気がしたので保存・再生するソフトウェアを書いてみることにした。

というわけで出来たものこち

https://aakeeper.appspot.com 驚くほどあっさりできてしまった。

でも、今はできた物自体の話はいい。それより作る過程で色々感動したのでその話をしたい。

今や OSS には巨人の肩どころか常にジェット機に乗ってるくらいのツールが揃っている

今回使ったのはざっくり以下のもの

これらのツールに関して、自分殆ど学者だ。

Quasar FrameworkNode.js も Electron も使うのははじめて、他はちょっと触ったことあるけどそんな詳しくない。 ES もあまり好きでなかったので基本的には避けてきた。

にもかかわらず、全体で余暇時間2週間分くらいで出来た。

Quasar Framework は、とにかく物凄くよく出来ていてびっくりした。今回 Electron モードしか使っていないけど、本来はこれで SPA/PWA/モバイル(Cordova) アプリケーションが作れるという凄まじい対応幅のプラットフォームになっている。着手時に 1.0beta の予告だけあるというタイミングの悪さ(数日後に出た)だったので、 0.17 系を使った。しかし、それでも十分すぎるほどよく出来ている。

ES は今でも嫌いな点は多いんだけど、今回 async/await を使って感動した。これは素晴らしい。他の言語にも欲しい。

CoffeeScript趣味だけど、とにかく短く書ける点が素晴らしい。あれは終わったという人もいるが、記述量の少なさは js 系では他の追従を一切許していない。今回みたいな急いでいるケースでは、括弧の世話を焼いたり eslint おばさんと語り合う時間はない。CoffeeScript ならコンパイラが全部上手くやってくれる。

HTML5 ベースGUI は今や chronium の各種アクセラレーションのおかげで、並のポータブル GUI ツールキットよりずっと高速に動作する。

また、Vue.js + pug は非常に記述量が小さくて目的の画面がすぐ作れ、カプセル化がしやすコンポーネント再利用も容易だ。

Babel/Webpack は正にバッドノウハウを煮詰めて固めた感じだが、こいつがバッドな部分を吸収してくれるおかげで開発者正気を保てる。ただし追求しだすとSAN値が減る。

ユーザから見ると、Electron 製のアプリメモリをやたら喰う、少しもっさりしている、配布バイナリが巨大になるという問題は確かにある。

しかし、そうだとしても何より、とてつもなく高速に作れて、各種プラットフォームで割とちゃんと動く。

自分は色々初めてだったので結局2週間分くらい掛かったけど、前提知識が揃っている人なら本当に数日でできたりするんじゃなかろうか。

状況は良くなっている

つい数年前まで、クロスプラットフォームアプリケーション作成というのは本当に本当に大仕事だった。こんなに早く手軽に書ける事は無かったし、ユーザ側でもラインタイムインストール必要とか環境側のハードルも非常に高かった。

自分は今まで知らなかったけど、最早そういう時代は終わっていた。

もちろん過去に数多くのクロスプラットフォームフレームワークが登場しては消えていったのと同じく、Electron もいつかその仲間入りをするだろう。

でも確実に、びっくりするくらい状況は良くなっている。

興味があるけどまだ触ってないという人は、ぜひ試して感動を味わってもらいたい。

Happy Hacking!

2019-02-17

フレームワークとは・・・

.netとは何か調べていた。

.netとはWindows用のフレームワークらしい。

ここで言ってるフレームワークとは、大量のライブラリコレクションらしい。

ライブラリコレクションとは、良く使われる関数クラスをまとめたものらしい。

ぼんやりプログラム言語のようなものイメージした。

まり.netとはWindows用のプログラム言語

この認識は正しい?

エンジニアが35歳までとか言われるのがわかった気がした

自分が働いてるところは割と余裕があるほうだ

毎日1,2時間ネット見てられるしネット制限はないから好きなページを見れる

新しい情報仕入れたりライブラリフレームワークを使ってみたりもできる

暇な時は1日することないが待機はしてないといけないので、いろいろ試せて使えるツール技術も増える


だが、大手づとめの知人はかなり忙しいらしくネット見てる余裕はないし、そもそも許可されてるページが限られているらしい

そういうところに努めている人は新しい情報に疎くなる

就職からの知り合いなのだが、昔はいろいろ自分で調べていて詳しい人だった

しかし今では、古い方法いつまでもやってる人以外では当たり前になりつつあることでも知らなくて、話していて初めて聞いたと言われることが増えた

調べてる余裕がないらしい


本来業務中は仕事するべきだから、新しい情報を調べたり実際に使ってみるなどは業務時間外にすべきというのもわかる

しかし、終電まで仕事していて休日出勤もあるようなところでそれは厳しいだろう

それでも趣味仕事な人なら、数少ない休みの日にそういったことをするかもしれないが、そこまでする人は少ないと思う


仕事になると、新しいものをあれもこれもやるというのは慣れるまで効率がよくないし、慣れたものを繰り返してるほうが効率がよいので慣れたものやらせることが多いと思う

そうなると慣れたことに関しては強いが新しいものには弱くなる

業界的に廃れるのは早いほうだから同じことだけでは 10 年も 20 年もやっていくのは難しいと思う


いつか新しいものに移らないといけなくなるが、情報ほとんど仕入れられていない期間が長いとその難易度も上がる

私自身、基本暇な会社だが、忙しいとき終電まで関係ない調べ物でネット見てる余裕ないときが1, 2ヶ月続いたりはする

その後、いつものように調べてみるといろいろ変わっていてブランクがあった分追いつくのが大変だった

それが何年も続くと、新しくそ業界に入ってきた人とそこまで変わらないくらいの全然知らないところに来た気持ちになると思う


若いはじめての人ならいろいろ自分で調べる体力があったり楽しさもあってできる人が多いと思う

それに比べて、今までのが使えなくなる辛さもあるし、年齢を重ねて新しいのに適応するのに疲れてきてついていけなくなる人が増えてくる

そういう人が多い年齢が 35 歳くらいなんじゃないのかと思った


実際、私の会社だとそれくらいに余裕があるからか、 35 歳を普通に過ぎてるのに社内ではトップクラスに詳しい人がいる

同じこと繰り返してるだけじゃなく常に新しいもの調べたり試したりしてるようなタイプの人だし、経験年数の多さがそのまま力になってる感じで多少詳しい若い人では全然届かない


これは一つの理由なんじゃないかってだけで全員がそうではないかもしれない

だけど、仕事中に常に新しいもの適応していける程度に自由にできる時間を作るべきなんじゃないかと思う

技術についていけなくなれば、古い人やめさせて新しい人を入れればいいやって考えのブラックよりならともかく、長く続けてもらいたいならそういう時間を用意するだけで結構変わると思う





2019-01-29

anond:20190129122704

現代のまともなフレームワーク使ってりゃ勝手にやってくれるところだから気にしたことないわ

2019-01-28

1年前の「MMD日本3DCG破壊した」について

https://anond.hatelabo.jp/20180207165151増田だ。見覚えあるエントリタイムラインに現れ、なんで今拡散されているんだと驚いた。

色々ブコメやらツイートやらの反応があったので興味深いと思った反応に対する意見とかを落書きがてら書こうと思う。このエントリも書ききれなかったことを何度か加筆していることは許してほしい。

ブコメよりもTwitterでの反応が多いようで、以下の内容はエゴサした中から拾ってる物が多い。(https://twitter.com/search?f=tweets&vertical=default&q=MMD%E3%81%AF%E6%97%A5%E6%9C%AC%E3%81%AE3DCG%E3%82%92%E7%A0%B4%E5%A3%8A%E3%81%97%E3%81%A6%E3%81%97%E3%81%BE%E3%81%A3%E3%81%9F&src=typd)

全体的にはTwitterMMDerが多く、ブコメOSS系の開発者が多いように感じた。

また、記事を読まずにタイトルだけでMMD自体への批判である条件反射している人も多かったようだ。

明らかに煽るタイトルにしたのは増田のせいなので仕方ないのだが、MMDについて全否定しているつもりは全く無いので前のエントリ最後まで読んでほしい。いっそ記事名を「ガラパゴス化した」に書き換えるべきかもしれないがもう遅いか

逆に、あのような煽るようなタイトルの中で冷静に読んでくれてブコメなりTwitterなりで意見を書いてくれた人には本当に感謝している。

なお、ここに書いていない反応に対しても賛否わず理解を示したものもある。

「今のVRC/Blenderを中心としたモデリング技術について、まったく知らなそう」「VTuber全盛期で皆がUnity使ってる時代に何を言ってるんだ」

これは申し訳ないとしか言いようがない。1年前は一過性ブームだろと思ってたがVR ChatもVTuberも一大ジャンルになった。それにも関わらず自分VRC界隈の情報を追ってないのでその辺で認識が不足しているのは言い訳できない。

VR Chat周りのモデルに関する雰囲気自分でも調べてみるが、気が向いた人がいたら教えてほしい。

「敷居を下げたのは事実」という趣旨の反応

同じような反応が多数あったが、それには同意する。そもそも先のエントリでもそれは否定はしていない。

ただし、下がった敷居から入った人がMMDからツールに移った瞬間に見向きもされなくなるのが3DCG動画画像コミュニティにとって問題だと思っている。

Blenderを使えばもっと凄い作品が作れるような動画投稿者でも、再生数を集めるには「MikuMikuDance」というタグに縋るしかない。

MMD視聴者は「制約が多いMMDで作ることが凄い」「MMDでここまで作れて凄い」というメガデモに近い発想を持っているので、BlednerとAfterEffectsで美麗な映像を作ったところで「MMDじゃない」として一蹴されるだろう。

実際、アイマス動画でPMXデータをBlenderか何かに読み込ませた動画において「でもこれMMDじゃないじゃん」といったコメントを何度か見かけた。もちろんそれが全てのユーザスタンスではないのは承知しているが、一定数そういった声がある時点で投稿者障壁になるだろうと思う。

3DCGMMDが分断してしまっているこの状況を「MMD3DCG破壊した」と書いたつもりである

これもVRCの活発化で状況が変わるといいんだが、どうなるかわからない。いや、もしかしたら既に変わっている可能性がある中、昔の認識でこのようなことを思っている可能性があるのでそうであれば申し訳ない。

追記)「MMDerを批判してるというより、MMD作品しか伸びないからどんなにすごい技術を持ってる人でも次のステップに上がらずMMDに留まってる→この現状が『日本3d技術破壊』している。…という解釈であってるかな。」

まさにその通りで、ちゃんと読んでくれて嬉しい。

増田もこの人みたいに整然とした文章がきちんと書ければよかったなという反省があるし、書けていれば炎上はしなかったんだろうなと思う。

「いまだにIE使ってる人が多くてヤバいって話してるときにおまえ一人がChromeインスコして解決すんのか?」

まさにそうで、MMDマジョリティである時点で一人がどう動こうと変わらないのが現状。

MMDを超えるプラットフォームが作れない時点で敗者」

同意。確かに負けは負けだしBlender等が勝っているとかは思わない。

日本企業でWindows XPIEが使われ続けるのと似たようなもので、劣っているものでもそれじゃないと満たせないニーズがあるんだなと思う。

アマプロをごちゃまぜにして『3DCG』って考えるのは良くない」

昔のニコ動もそうだが、最近アマプロの境目が曖昧じゃないか

アマチュアが作成したデータプロが使うこともあるし、アマチュア投稿者商業案件を請けてプロになる機会も増えているだろう。

「じゃあオープンソースMMD互換ソフトウェア作ってよ」

文句を言うなら作れ」って子供かよ。仮にMMDOSSになればコミットするつもりはあるが、それでは不十分か?

樋口が秘匿している仕様を解析してフルスクラッチするスキルがないとMMD界隈に疑問を呈することもできないのだろうか。

追記)「MikuMikuPenguin等のOSSがあり、それにコミットせずにこういう記事を書いているのは口だけであり甘え」という指摘があった

開発が4年前に停止したこと宣言されたOSSコミットするのは難しいだろう。そもそもサードパーティOSS開発が停止してしまう状況自体に苦言を呈している。いや、元のエントリではそう書いてなかったか後出しするのは卑怯だな、すまない。まあとにかくそういう風に考えている。

本家OSSに動かない限り、「MMD」のOSS化は進まないと思っている。

追記)「これ(MMDの外部レンダラー連携ツール)すら知らなかったみたいだしOSSのこともろくにしらなそー。OSSは『自分要望を投げつけたら勝手に好みのものが出てくる打ち出の小槌』じゃねーぞ。」

そんな革新的ツールがあったのは知らなかった。偉そうなエントリ書いたわりにリサーチ不足なのは申し訳なく思っている。

しかし、MMD固有のサードパーティツールを知っているかどうかとOSS分野に詳しいかは全く別ではないだろうか。議論すり替えだろう。

増田は確かにMMDBlender関連のOSSコミットしたことはないが、某Webフレームワークコミッタである。もちろん匿名なのでこれも嘘と思われても仕方がないのだが。

そのフレームワークに限らず、Issueで提案した改善点を議論の末にwont fixにされた経験もあるので打出の小槌のようには捉えていない。特にコミッタの人数が数百に上るようなコミュニティではIssueやPull Requestの多くがwont fixになるのは知っているつもりである

MMDは他のソフトに比べて低品質からオープンソースにしてどんどんアップデートしろよという話かな(自分がするとは言ってなかった)」

これもOSS自体に馴染みがない人には分かりづらいかもしれないので補足しておきたいが、「オープンソースにしてほしい」という話は他力本願で「アップデートしろよ」というスタンスになるのではなく、「自分も開発に関わらせてほしい」という意思である

スキルドメイン知識問題コードに落とし込めない部分があってもIssueで議論に加わることはできるし、それがオープンソースの強みである

これは私のような文句を言いたがるタイプ人間だけでなく、純粋MMDファンである動画作成者たちが抱いている不満やバグ報告も反映されやすいことを意味している。

現時点でMMDerの方々もMMD完璧ツールだとは考えていないだろうし、OSS化されるとユーザにもメリットが増えると思うのだが何故これを否定するのかがわからない。

もちろん、開発者である樋口氏が「OSSにしたくない」と意見を表明するのであれば分かるのだが、何故MMDユーザまでOSS化を否定するのだろうか。

神格化とは言いますが、自分が大いに楽しませてもらってるツールしか無料)の開発者に敬意を払うのは当然では」

敬意を払う事と批判的な立場を取ることは別では。

コミュニティのためにならないことであっても盲目的に肯定するのは敬意ではないと思う。

「いわばMMD文化の外の人と意見が相容れないのは、彼らは利用していないか感謝気持ちがない」

まず増田MMDやPMX Editorの利用者だったことが伝わっていないせいもあるだろう。利用した上での弱点を述べているのだが、それは感謝が足りないということになるのだろうか。

「不備や弱点を指摘することはそのソフトウェアが好きだから行う」というのはOSS特有文化なのか?よくわかっていない。

「大多数がアニメゲーム二次創作から モデル作ってる人はあまりオープンにして欲しくないだろう」

モデルライセンス曖昧なのはこれが一番大きい理由なんじゃないかと思っている。CCライセンスなんかで二次創作モデルを配布すれば大問題だろう。

ただ、モデルではなくMMDソフトウェア自体オープンにしても問題ないんじゃないかとは思う。

「「基本的無料」で手に入る大量の『MMD用3Dモデル存在する』ってーのが妬ましいんじゃないかなぁ。勝手に羨んでて良いから、こっち来んな。」

前の記事でも上にも書いている通り、自分が主に問題だと思っているのは「MMD」と「3DCG」が分断された点である

これは個人的な話になるが、自分自身が動画を作ったときモデルデータをすべて自力作成していたので潤沢なリソースがあることに魅力は感じていなかった。

もちろんリソースを魅力に感じている人も居ると思うので「妬ましいんじゃないかな」という指摘自体否定できないが、増田が指摘している内容とはズレているのでちゃんと読んでほしかったと思う。

記事冒頭に貼ったTwitter検索リンクを見てもらえれば分かるが、このツイート以外でもMMDerからは「羨ましいんだろう」という反応がかなり多かった。少なくともこのエントリはそういう意図ではないのだが、どうしてそう解釈されたのかはわからない。

「件の記事の方はじゃあ自分ではモデルを作って配布したり作品を完成させているのか?」「書いた人MMD弄った事ないでしょw」

おそらくエントリの中身を読んでいないと思うからもう一度書くが、先のエントリではモデリングソフト〜PMX Editor〜MMDワークフローが面倒であるということを書いている。弄ったことないのに知っていたらそれはそれですごい。

増田は数は少ないがニコニコ動画、BowlRollにPMXデーはいくつか上げたことがある。その上で思った事が先のエントリである匿名日記だしID晒すつもりはないので「嘘乙w」と言われたら反論しようがないのだが。

実際、この経験からボーン入れ・リギングが大変面倒なことを痛感し、キャラクタモデリングキャラクタアニメーションをやっている人には頭が上がらないなと思うようになった。

からモデラーMMD自体貶めるつもりはないし、むしろ尊敬している。あくまで先のエントリコミュニティ雰囲気MMDのものが孕む問題についての指摘である

MMDCGに不満があるなら貴方の素晴らしい作品を見せてもらいたいなぁ。CGにはCGで殴るべきでしょう。」

CGがわからないくせに文句を言うなと言いたいのかもしれないが、素晴らしい作品を出しながらコミュニティのあり方について文句を言うのは気が狂っていると思う。それただのマウンティングゴリラだろ。

BlenderMaya作成し、レンダリングした画像を添付しながら「MMDオープンソース化すべき」と主張する人間が来た場合自分だったらキレてしまうと思う。

「変えたいのなら記事を書いた貴方が頑張ればいい。偏見しかない意見しか言えない人には無理だと思う」

現にこの記事でも「勝手に羨んでて良いから、こっち来んな」という反応を受けているし、以前はVR系の開発者がPMXを読めるようにしただけでMMDerがブチ切れている。(https://togetter.com/li/984614)

そんなコミュニティに対して「頑張ればいい」って無理だろう。北センチネル島先住民に会いに行くような真似は誰もしたくないし、したところで何も変わらない。

自動車でいけば速いのに自転車(MMD)を限界チューンして走ってるみたいなところは確かにある」

すごく的を得ていると思う。

もちろん「趣味なんだから自転車に乗りたければ乗れば良いじゃん」「お前は車でも飛行機でも使ってりゃいいだろ」っていう話は分かるのだが、前述のVRの件のように自転車乗りが車道を塞ぐような事は避けてほしいとは思う。

追記)「ただ的は射てほしかった」

増田ドヤ顔誤用をやってしまったのかと思って焦ってググったのだが、どっちでもいいらしい。(https://twitter.com/IIMA_Hiroaki/status/412139873101807616)

勉強になった、ありがとう

のじゃおじの信者かよ

彼(彼女)には申し訳ないのだが、のじゃおじ氏はむしろ好きではない方だ。彼が批判されたことに怒りを覚えてエントリを書いたわけではない。

[]2019年1月27日日曜日増田

時間記事文字数文字数平均文字数中央値
0012621683172.139
0164588291.948.5
02254197167.930
0313107382.555
0412103085.861.5
05161675104.717.5
0628262093.650
0728267695.648
0852377472.648.5
0989854596.048
101401299092.832.5
1197903493.156
121321286797.533.5
13141927165.834
141501485299.039
15123921174.949
16106777473.346.5
171331142585.936
1812113768113.837
191241041284.032
2013015042115.741.5
2114517604121.460
222161554272.035.5
2315819913126.053
1日236923286098.341

頻出名詞 ()内の数字単語が含まれ記事

人(190), 自分(157), 今(107), 女(99), 話(93), 男(83), 増田(80), 日本(75), 好き(69), 必要(65), 女性(64), 問題(63), 感じ(58), 前(58), 人間(56), ー(51), 子供(51), 仕事(50), あと(49), 普通(46), 社会(46), 気持ち(40), 意味(39), 関係(39), 気(39), 結婚(39), 国(38), 他(37), 時間(37), ワイ(35), 理由(34), 頭(34), 全部(33), 相手(33), 一番(33), 現実(33), 猫(33), セックス(32), 無理(32), 理解(32), 最初(32), 存在(32), 言葉(32), 今日(31), 金(31), 日本人(30), ネット(30), 場合(30), バカ(30), 最近(30), 人口(30), 結局(29), 世界(29), しよう(29), アニメ(28), 時代(28), 他人(28), フェミ(28), 一緒(28), 人生(28), 毎日(28), 目(27), 昔(27), 家(27), 誰か(27), 別(26), 幸せ(25), 漫画(25), 事実(25), ただ(24), 批判(24), 男性(24), しない(24), 作品(24), 維持(23), 方法(23), じゃなくて(23), 子(23), 親(23), ゴミ(23), 否定(23), 先(23), 嫌(22), 一人(22), 生活(22), 出産(21), 嵐(21), ダメ(21), レベル(21), とこ(21), 逆(21), 大学(21), 絶対(21), 大事(20), お金(20), 学校(20), 可能性(20), 状況(20), 内容(20), 自体(19), 悪(19), 勝手(19), 顔(19), 趣味(19), どこか(19), 全員(19), 解決(19), 2019年(19)

頻出固有名詞 ()内の数字単語が含まれ記事

増田(80), 日本(75), ワイ(35), フェミ(28), じゃなくて(23), 可能性(20), 2019年(19), ニート(18), アメリカ(17), 東京(16), 先進国(15), プリキュア(15), わからん(15), 人口減少(14), 自分たち(14), いない(14), twitter(14), スマホ(14), ADHD(13), カス(12), 元増田(12), 毎日(12), はてブ(12), 出生率(11), 一緒に(10), ブコメ(10), 韓国(10), 異世界(10), PC(10), ハイファンタジー(10), 中国(10), 女に(9), Twitter(9), 共同体(9), ポリコレ(9), hatena(8), s(8), ???(8), Go(8), 基本的(8), 平成(8), 非正規(8), 被害者(8), 活動休止(8), 価値観(8), ジャニーズ(8), 被害妄想(8), この国(8), ブクマ(8), キモ(7), ミサンドリー(7), 託児所(7), 犯罪者(7), 1月26日(7), ポケモン(7), ありません(7), な!(7), 性役割(7), なんだろう(7), 消費税(7), …。(7), キチガイ(7), ツイッター(7), Rails(7), ネトウヨ(7), 昭和(7), KKO(7), 何度(7), なのか(7), ブクマカ(6), Amazon(6), 一日(6), pic(6), 男女平等(6), 大坂なおみ(6), 夫婦(6), イケメン(6), 大阪(6), metoo(6), 日本会議(6), co(6), 沖縄(6), 生活保護(6), なんや(6), 1月27日(6), VPS(5), S(5), 個人的(5), プレイ(5), アメリカ人(5), 山口(5), 2年(5), AI(5), とはいえ(5), なおみ(5), マッチングアプリ(5), 脳内(5), 性差別(5), t(5), メンヘラ(5), 武井壮(5), w(5), OK(5), CM(5), エロ本(5), ローファンタジー(5), 名古屋(5), なんの(5), ツイート(5), my(5), NG(5), 1回(5), Webサービス(5), 分からん(5), 9割(5), お姉さん(5), is(5), 非モテ(5), エヴァ(5), フレームワーク(5)

本日の注目単語 ()内の数字単語が含まれ記事

1月27日(6), ローファンタジー(5), ういろう(12), 1月26日(7), ハイファンタジー(10), マスタード(5), 学童保育(4), 最高学府(3), ナルホド(3), 活動休止(8), wife(3), 嵐(21), 出生(9), 虐げ(12), 出生率(11), 2019年(19), 思いやり(6), 女に(9), ADHD(13), すり替え(6), 男尊女卑(9), 人口(30), 先進国(15), 非正規(8), pic(9), 解散(7), 転生(13), プリキュア(15), 教師(16), 幸福(13), 優遇(14), 出産(21), ニート(18), 猫(33), 維持(23), コーヒー(11)

頻出トラックバック先(簡易)

絶妙に古い発言をしてください /20190127060427(40), ■ADHDの疑いがある俺、もう妻とはだめかもしれない /20190127042317(21), ■どうやったらセックス脳を克服できるんだ? /20190127002056(19), ■風俗のやめ方教えてほしい /20190125231116(17), ■お土産ういろう だった /20190125213314(15), ■異世界生モノって最初から異世界にいちゃダメなの? /20190124010431(11), ■姪「おじちゃん、お家に帰りたい」 /20190127164353(11), ■女子大生になって1年 /20190124014327(9), ■日本アニメプレゼンスは、なぜ下がってしまったんだろう? /20190127211255(8), ■16歳の女の子にめちゃ×2 アタックされた俺! /20190127070600(8), ■俺の思う結婚生活 /20190126235410(8), ■夜景全然惹かれないんだけど /20190127125605(7), ■コメダ珈琲コーヒー500円て高すぎないですか /20190127143604(7), ■マルクスくんさん、突然他人事のようにミサンドリー批判 /20190127130905(6), ■母「大坂なおみ日本人じゃないでしょ」→大坂なおみ全豪オープン優勝後→ /20190127114003(6), ■おにぎりが食べられない /20190127065805(6), ■Webサービスの試作品 /20190127111339(6), ■あの演説を支持してる奴等は本物のバカ /20190127105435(6), ■日曜のこの時間になると今日も何もしなかったなあ /20190127204417(5), ■中途半端 /20190127094832(5), ■職歴の無さをバカにされる /20190127194356(5), ■「よかったら私のパパになってください」 /20190126223649(5), ■ /20190124172107(5), ■最近ブクマカ /20190127082850(5)

増田合計ブックマーク数 ()内の数字は1日の増減

5965479(2519)

2019-01-27

anond:20190127120317

フルスタックフレームワークモノリスを作るのではなく、機能を分解してマイクロサービスに変換する。

RailsアプリGo移植する段階では、アーキテクチャーの変更、見直し必要

多分ノウハウがどこかで公開されているはず。(ありがちなパターン?)

anond:20190127120209

問題GoフレームワークRailsと比べてショボイこと?

自作するならGoを使う意味がない。

anond:20190127115034

欲張って1段階でまとめたくてもできない場合妥協案。

  1. Railsですぐに試作する。
  2. Goリファクタリングする。

バックエンドはこの2段階でいいかな?

移植するときになるべく手数を減らすには、Railsと似たWebフレームワークGoにもあれば良い。

anond:20190127111339

 

その他:PythonPerlJavaScalaErlangElixir、…好きなのを使えばいい。

アプリWebサービス開発してると必ずぶつかる『UIダサい』の壁

センスがないのが悪いって言われたらその通りなんだけど、

CSSフレームワークとか使ってもダサいもんはダサい

ちょっとお金かけるとかでも全然いいんだけどなんとかならんもんかなぁ

例えば増田晒したらダメ出しくれたりするかな

2019-01-22

プログラマ業務中に身につく知識

業務ではこんなことやるんだな。テストってこういうことか。ここは案外適当なんだな。この製品プログラムはこんな感じのプログラムになってるんだな」ってことが業務でわかる。だけど言語とかフレームワークとかの仕様業務では別に身につかない、なぜならそういうのはほぼOJTから(聞けば答えてくれるシステム)。

最初研修言語フレームワーク一つずつでも覚えさせてもらえばだいぶありがたいと思うけどそういうの無い場合本当にそういうのは独学になる。家に帰って。または先輩にたまに聞くとか(ちょびちょびと…)。そんなんなら知恵袋で聞くのと変わらないし。

業務で学べることはただただ「これは実際こうやって動いてるのか」って中身が見れること以外は少ないと思う。言語フレームワークサーバーバージョン管理システムとかは自分で覚えないといけない。というか覚えられない。時間かかる。働いてる中での独学なんて時間そんな無いし。

2019-01-19

目標設定のフレームワークとして意識高い人がよく言う「SMART法則」というものがあるんですが、SはSpecificだとかMはMeasurableだとか頭文字をとっていく中で「R」に該当する英単語がRelevantだとかRealisticだとかResultだとか、見るたびに内容も意味も変わるので面白いです

2019-01-18

大規模SI自分マッチしない理由

そもそもITゼネコン主導の大規模開発は悪評まみれで、天国案件なんて数えるほどしかないと言われる。

なので誰がやってもしんどいと思うが、特に自分には全く合わなかった。


自分プログラミングは、動かす前に「これで行けるだろう」と確信しながら、動かしてみて抜けや漏れが発覚するタイプなので、コード品質は多分悪い部類に入るだろう。

つーか、仕事なんて楽に済ませたいから、コードなんて可能な限り書きたくないというのが一番にある、かなり独善的人間だ。


一方で大規模SIプログラマなんて、基本的ライン工か調整役以外お呼びでない。

そしてコミュ障でもある自分必然的に、もらった設計書の長ーいフローをひたすらコード翻訳するという、まさにライン工として身を粉にして働くしかなかった。

それこそif文の後のelseが何ページも先になろうが、ループが何重にネストしようが一切気にせず、可能な限り設計に沿うようコードを書き続けた。

元々コードを書かずに済ませたい自分には、正直目が眩みそうな作業だったが仕方ない。

しかし上述のように元来不注意な人間なので、品質は恐らくメンバーの中では最低レベルの代物を量産する結果となった。


でも、本当にしんどかったのはテストである

コーディングスケジュール的に余裕なかったが、テストに至っては必死にというか、死に物狂いで頑張らないと遅れてしまうくらい、作業量が半端なかった。

ちょっと込み入ったメソッドになると、それだけでテストケースが20とか30とか相当な数になるので、ケースの抽出から始まって、最終的にレポートにまとめてカバレッジと一緒に提出するまで、地獄のような作業連続になった。


最終的には体調不良理由に「すんませんクビにしてください」と言って現場を抜け、その責任を取って僻地に飛ばされ今に至る。

そんなことはどうでもいいのだが、それ以来、テスト自動化ツールに対しては、理屈抜きに憎しみしか沸かないようになった。

フレームワークの便利さを推す記事とか、むやみに持ち上げるヤツは一切信用できなくなったし、オブジェクト志向をやたら崇高で革命的なもののように吹聴するやつはもっと信用できなくなった。

そんなもの自分にとって、楽に仕事をする味方にならないものであることがハッキリしたからというのが理由である

2019-01-14

anond:20190114234205

基礎文法さらったらあとは自分でなんかアプリとかWebサイト作る方にシフトしたほうがいいよ

有料会員ならPythonとなんかフレームワークアプリ作る講座もあったと思うけど(既にやってたらごめん)

2019-01-11

案件的にはRailsからLaravelに移ってる気がする

個人的評価としては、言語PHPよりRubyの方が洗練されているけど、フレームワーク込みで考えるとLaravelの方が上

2019-01-10

会社webデザイナー無能すぎてヤバいwwww

去年の冬に転職したweb系のプログラマー

今の会社webデザイナー無能すぎてしんどい

以下愚痴

1. photoshopwebデザインすんな!

photoshopで作ったpsdのwebデザインを渡されて、フロントエンド担当HTML/CSSコーディングしてるんだけどどうなのこれ?

なんでphotoshop使うの?webページ作るんでしょ?最初からHTMLで書けよ?

いや分かるよ

ラフの段階でphotoshopでササっと書いた方が客と調整しやすいもんな

でも最終的にはHTMLで出すんだからデザイナーHTML/CSS書いて来いよ

それをなんか知らないけど、普段使わねーphotoshop開いてルーラー出して、

「ここと、ここのボックスは10pxだからmarginを...」

「ここは、webフォントの〇〇を使おう」

とかフロントエンド担当相談してんのw

バカなの?死ぬの?

最初からデザイナーHTMLで書けよ

UIライブラリフレームワークも充実してんだからphotoshopで大枠を調整したら、ササっと書けよ自分でよ

photoshopで書かれた夢いっぱいキラキラデザインの実現可能性をなんでこっちで検証しなきゃいけねーんだよボケ

今の会社含めて2社しか経験してないので、一般的かどうかは判断できないが、前職ではHTML/CSSまでデザイナーの人が書いてたぞ

(zeplinが吐く糞みたいなコードじゃなくて、ちゃん構造化された綺麗なHTMLね)

本来はこうでしょ?

「このボックス内の文字が溢れたらどうなりますか?」

「このボタンマウスオーバーしたとき画像下さいとか」

レイヤーマウスオーバー時の画像保存してあります」(←ふざけんなww

かいう下らんやり取りを止めろカスども

photoshop画像編集ソフトであって、webページ作成ソフトじゃねーんだよ!そんな事も分かんねーのか?

2. webデザイナーphotoshop職人HTML/CSS全然理解してない

webデザイナーだよね?あんたらは?

webが頭についてるならwebの事ちっとは理解すべきなんじゃねーの?

「いやCSSよく分かんないんでじゃねーよ!」

Reactを書けとは言わない

でもせめて、CSSフレームワーク, flexbox, grid layoutとかは知ってるべきでしょ?

photoshop簡単に作れてもwebページだと大変なことだってあるんだバー

psd渡してあとは頑張ってね!でよくwebデザイナー名乗ってるなw

webのこと分からないwebデザイナーなんてマジで笑いごとで済まねーぞw

建築デザイナーの人が大工までやりなさいと言ってるんじゃない

でも建築基準くらいは知っておくべきでしょ?

webデザイナーならHTML/CSSを最低限知っておくべきなんじゃねーの?

である程度分かるなら、photoshopで頑張って画像作る手間でHTMLを書けよと言いたいんだよ

いい加減目を覚ませ!!!

HTML/CSS分かんねーなら今すぐudemy勉強してこいハゲ

3. そもそもデザイン要るの?

そもそも何でもかんでもwebページをポスターみたいに着飾るんじゃねーよ

巷に溢れてるキラキラデザインwebページ糞使いにくいぞ

ランディングページならともかく、よく使うwebアプリを着飾るんじゃねーよ、開発もしにくい、使いにくいしでまったく良いこと無い

パララックスもモーダルウィンドウもうぜーとしか思わんww

大抵Craigslist, Hacker News くらいのデザインで十分なんだよ

それを何でもかんでもデザイン所為にして、下らん工数使って何がしたいんだか

UI/UXを考えたデザイン変更じゃなくて、糞webデザイナーのオシャレ(笑)に付き合うくらいだったら、もっと他に開発すべきことが無いか考えろ

そのwebサイトが当たらない理由デザイン所為にするんじゃねーボケカス

まとめ

webデザイナーカスだったけど、前職に比べて給与は上がったから、しばらくは居る

でもいつかこいつらを首にしたい

あとこいつらの肩書Webコラ画像職人に変えたい

2019-01-04

anond:20190104054605

プログラマってコミュ障いから教えるより自分で書いた方が楽って方向に逃げがちじゃね。

というかどんだけ苦痛に満ちた職場にいるんだよウケる

テンプレコピペだけで機能を実現できるようにするためにフレームワークとか導入するんだけどまあそれは分野次第なので

何でもかんでも長期間試行錯誤を強いられれるのはその分野の最前線にいるのか

銀行みたくネットにつなげない環境なのか

前者なら燃えるんだけどな。

2019-01-03

anond:20190103120108

言語ごとに充実してるライブラリフレームワークの違いがある関係で、機械学習ならPythonとか脆弱Webサイト作成ならPHPとかそれぞれ得意分野が別れる

そういうのを把握するのが言語学習のメイン

条件分岐とかの書き方は言語に入門した初日カバーし終える内容に過ぎない

2018-12-29

現場の他社の人たち、みんな口が達者で

さすがお客さんの会社系列だけあって、教育もしっかりしてんだろうな〜とか関心してた

けど、バグをけっこう出してた

バグ自体はまぁ、テストで出るものだとは思うが

プログラムコメントデバッグログ出力もきれいに削ったものだった

DB周りの処理やら他機能連携やら、異常としかさな

複雑な機能なのにこれでよく単体テストやれたなと思った

設計書で求められているログは出力している、とは言っていたが

そう思うとうちの会社の同僚はインターフェース周りの文書の食い違いに実装前に気づいて確認取ってたり

DB周りのエラーログを出力するようフレームワークに組み込んでたりと

実装周りではい仕事してるなと思った

トークはうまくない人が多いけど

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん