「バックエンド」を含む日記 RSS

はてなキーワード: バックエンドとは

2018-04-29

巨大トラフィックをさばくシステム

TwitterFacebookのようなサービス日本発で作りたいね

インフラクラウドも併用するとして、バックエンドはどうやって作ればいいかな?

Elixir/Erlangは、使いやすいでしょうか?

2018-04-25

介護が始まりそうだから仕事辞めようかな

親の介護しながら

家で仕事ってできるのだろうか

プログラミング可能です。

一通りフロントエンドからバックエンドまででWebサービス作れるって状態です。

Webサービスは作るのは簡単なのだが、

それでお金が稼げるかはまた別問題なんだよな。

2018-03-23

anond:20180323154414

AIバックエンド部分を作ることを一般web系とは呼ばん…

AI使ってても実質awsAPI叩いたりしてるだけだったりして、そういうのはもちろんREST APIぬっこぬこしてるだけだからweb系という括りになるけど。

2018-03-20

文系エンジニアなんて死ねばいいのに

文系エンジニアなんて死ねばいいのに

俺、Webサービス作ったんすよ(Rails

俺、iOSアプリ作ったんすよ(Swift

俺、Macbook使ってるんすよ(タッチバー付13インチPro

俺、プログラミングスクールプログラミング教えるアルバイトしてるんすよ(そいつはそのスクール卒業生

これぞ量産型文系エンジニア()

懇親会で「皆さん嫌いな言語とかフレームワークはありますか?」と話題になると私は即座にRailsと言う。

すると文系エンジニアはみんな嫌な顔をする。

そこでちょっとお話をすると皆怯んじゃう。

「あのコマンドを打つと中で何が起きてるか知ってますか?」(知らない

ActiveRecord?生でクエリいたことあるインデックス意味くらい知ってるよね?」(書いたことない、適当なこと言う

へーその作ったサービスURL教えてよ

3分

「alert('XSS')」

Session?Cookie?(何それどんな味のクッキー

CSRF?(企業理念か何か?

百歩譲って学生エンジニアならまあセキュリティ無知なのは分かる。

しかしだな、文系エンジニアは「俺もハッキングしたい(笑)」な勢いで詳しく解説することを要求してくる。非常にウザい。

"

お前はよぉ!自分で探すってことをできねぇのかよ!?

"

しょうがないので優しく解説すると「君ってハッキングとかしてそう(笑)」「君将来ハッカーになりそうだわ(笑)クラッキング的な意味で)」

死ねよ。

文系エンジニアはこれだけではない

俺、Git使って開発したんすよ(GUIのSourcetree

え?バグちゃんテストしたんだけどなぁ(完全手動テスト()

デプロイ先は9割Heroku。(HTTPS対応

AWSGCP登録はしたものの使い方が分からなくて結局放置

SSH証明書を使わずパスワードオンリー

pwdcdしか知らない(Makefileを作ったことないからいつもネットコピペコマンド

見た目重視のTerminal(ネットコピペ設定)

最近聞いた文系エンジニアもっと面白い

新規事業を開発してる文系エンジニア集団がいた。

開発は順調、プロモーションをかけていざリリース

はいゴールデンタイム鯖落ち。復旧した時にはゴールデンタイム終了のお知らせ

理由CDNを刺してない、貧弱なプランの鯖(勿論ロードバランサなんか使ってない)

噂による無線LANルーターの設定も出来ないレベルらしい。

でも彼らは一応優秀な文系エンジニア高学歴サービスも作ったこともある、それなりの実績も持っている。しか文系だ。

こういう奴らがいるかちゃんとしたエンジニアを軽視される。黙って営業職に転職してこい。

まあでも大学じゃ作者の気持ちしか考えてないのだから当然のなのかもな(笑)


追記

残念な理系名前を書くだけ一発採用派遣SIer対象としてない。論外だ。

給料が安い?

そんなことは無い。400万以上貰える会社内定もらっているか嫉妬も不満も特に無い。

だがしかし、ムカつく。

そんな奴が同期にいたら蹴り飛ばしてやりたくなる。

そうさ、今はSwiftiOS時代だ。

だが見てみろ、あいつらのアプリバックエンドが無いんだぞ?意欲は認める。だがそれで胸を張ってiOSエンジニアなんて無理があるだろ?

2018-03-15

フロントエンドはいいぞ

バックエンドのように地味で制限も多くいつまで経っても新しいものがあまり出てこない退屈なところとは違う


から次に新しいツールが出てくる

同じツールばかりで飽きることがない

案件で新しいのを使ってみて、次の案件ときにはもう次のツールが出てきているから使っていける

同じものばかり使って新しい体験がないまま同じようなことの繰り返しという退屈さがない

常に新しい体験ができる


さらにはツールが多すぎる分、ツールも選び放題だ

自分にあったものを使えばいい

JavaScript 自体ウェブだとこれ一択だったから、オブジェクト志向だったり関数型だったり比較的いろいろな使い方ができる

それぞれに合わせてライブラリがあるから好みの使い方をすればいい

型がほしいならtypescriptなどのaltjsもあって自分の好きなもので作れるわけだ

一部○○するならこれ、などと言い切ってる人がいるがそんなことはない

いいところもあれば悪いところもあるし、欠点があるからそれを補った別のツールが出てくるわけだ

目的に応じたもの自分が好きなものを使えばいい


ついていけないという人もいるが、新しいのが出続けるというのを理由に避ける必要はない

新しいのについていけない、めんどくさいという人は古いのを使い続ければいい

新しいものを使うかどうかも自由

未だに jQuery やそれと同じくらいの時代からあるライブラリのみのサイトだって普通にある

それが悪いということもない

新しいもの価値があるなら使う、ないなら使わない

そういう選択もありだ

2018-03-12

どこまでがフロントエンドのやることなんだろう

私がいるところは、プログラマ/システムエンジニアフロントエンドエンジニア/バックエンドエンジニアとかの区分がなくひとりでなんでもやるところです

一応フロントエンドが好きで得意だと自称はしているもの一般的フロントエンドってどこまでするのでしょうか


デザイナがするような部分

ここは当然でしょう


最近では SPA のページも多いので単純な HTMLJS ではなくフレームワーク必要とされることもあります

ここもブラウザ側の話なので必要でしょう


SEOの都合などでJSレンダリングじゃなくサーバサイドレンダリングで、サーバから受け取るHTMLの時点で表示できる状態になってることを依頼される場合もあります

その場合サーバサイド言語に応じたテンプレートエンジンも使います

PHP なら BladePython なら jinja、 Node.js なら ejs という感じ


JSコードテストしたり gulp などのタスクランナーwebpack などバンドルツールを使うので OSコマンドラインツールも使える必要があると思います


サーバサイドの言語は別の人が作るにしても自分環境でそれを動かすためにサーバ構築は出来たほうがいいでしょう

VMOSインストールしてウェブサーバインストールしたり

Vagrant, Ansible 等で管理されているなら、設定ファイルを書くことはないにしろ実行する方法エラーが起きたとき簡単対象方法くらいは知っていないと不便かと思います

ウチの場合各自LinuxVMインストールして Ansible でという使い方なので気づきませんでしたが、考えてみたら全部設定済みの VM データを配布してくれるということもあるのかもしれません


データによって画面表示を変えるときに、それに応じたデータを作って画面を確認したいことがあるので、mysql や postgres などなどデータベースの知識必要になることがあります

SQL 書けなくても pgadmin みたいな GUI ツールで表を書き換えればいいのですが最低限の仕組みは知っていないと苦労しそうです

完全にフロント/バックが切り離されてるところなら、フロントエンド開発者向けにデータベースは使わずテンプレートエンジンに渡ってくるデータを好きに設定できる機能が用意されてるのかも?とも思います

サーバサイドの処理は不要クライアントサイドの動きのみを作るわけですから、決まった場所JSON ファイルデータがそのまま使われるならデータベースの存在を知らなくてもいいですし


ここまでできたらバックエンドよりフロントエンドのほうが何でも出来る人みたいに思えます

あとはサーバサイド言語を書ければもうサービスが作れてしまます

でもこれぐらいできないとすごく不便で、すぐに他の人に頼らないといけなくなるように思います

サーバ冗長化とかそういった部分はかかわらなくてもいいと思いますけど、Linuxデータベースなんかは自分でどうにかできないと周り誰もいないときに動かなくなったら作業進められななんてことがありそうですし

2018-03-11

自分自己肯定感が弱いと感じている

日頃、自分の興味のあることに関する課題発見し、それを解決するためにアプリ(小規模だけど)を開発し公開している。作ったものがたまにバズることがあって、その結果1日の広告収入が1万円を超えたこともあった。しかし、定期的に作ったアプリに対して使った技術要素やコーディング量を見返した時、これぐらいのものはxxさんなら自分より短時間かつ高クオリティで開発できるなと思うことがあるのだ。

興味があることに自分課題発見し実際に手を動かしているのですごい!みたいな話を聞いたことがあるが、理解はできても共感ができない。

常にネガティブ感情を抱いているわけでもなく、難しい箇所をうまくコーディングできた時は自分のことを天才だと感じることや、ミドルウェアを含むバックエンドからフロントエンドまで1人で開発できるようになり、昔の自分と比べて成長したと感じることはある。ただ、これらのポジティブ感情は一瞬で終わり、あっという間に上に書いたようなネガティブ感情自分支配するようになる。

レッドコーダーやKaggle Masterになるか未踏に採択されるなどのレベルに達すれば、自分を認めることが出来るような気はしているが、あいくそこまでの能力は持ち合わせていない。

https://anond.hatelabo.jp/20180311003723 を見て書きたくなった

2018-02-20

ヲタクエンジニアになりたい

わい情報学部就活生.ヲタク文化を支えているIT企業就職したいと強く思っている.お硬い企業で死んだ目でキーボードタカタするよりも,興味のある分野でキーボードタカタしたい.

ちなみにわいはWebフロントバックエンドばかりやってる.だからとりあえずWeb系かなって考えてる.

国内ヲタク企業は幾つかある.以下は順不同で適当に挙げたものである

pixiv
言わずもがな最近は絵の他にもグッズ販売即売会での決済手段提供など,幅広い創作活動に手を広げている.インターンにも参加したけど,良いところしか見つけられなかった.ここはマジで入りたい.
ドワンゴ
ニコニコ動画運営元.動画を中心に,ここも色々とやってはいる.が,最近は色々あって有料会員が激減したね...たつきを返して...
とらのあな
Twitter広告でよく目にする,「ヲタクエンジニア募集」.エンジニアはあまり居ないらしいが,だからこそ色々できそうで面白そう.

2018-02-12

anond:20180212215214

開発者じゃなくて、ビジネス系なんだけど、BI(Business Intelligence)のプラットフォームデータ分析する職種は、いまはどこもSQLの基本知識がほぼ必須なんだ。加工前のデータ抽出用として、あくまでも基本的知識だけ必要なのかもしれないけど

もともと少しコードを書いてたこともあったので、日曜大工的に自分サービス作ってみたいと思ってます

なのでSQLの基本をおぼえたらバックエンド実装の仕方も知りたい

2017-12-01

ツイッターブログ仕事関係の人も読んでいるので、ここで書く。ちょっとした事情Uターンして、とある地方のしがないWEB屋で働き始めたのだけれど、半年経って、もうこれは限界かもな、と思っている。


コードレビューが無い

社員が少ないし時間がないのもわかるのだが、コードレビューがあることによって、バグコード書いた人の目に届かない部分の影響への指摘などができると思うのだ。


テストしない

フロント状態管理が大変なので、限界があると思うんだけど、バックエンドテストコード書いて、ユニットテストくらいはやろうぜ、と思っている。まあ、自分も以前まではやっていなかったので人のこと言えないのだけれど。


タスク可視化されていない

何をやっているのかわからん上にダマで変更加えてmasterにマージちゃうしかも変更しているのはモデル。もちろんテストはしないぜ。masterからブランチ切って自分作業に取り掛かってみると、知らない変更が加えられている。影響範囲なにそれ美味しいの?状態なため、変更に伴って他の部分/モジュールにはバグまくりテストコードコケまくりエラーまくり


これを誰がやっているかと言うと、上司にあたる人間がやっている。ちゃんと技術的な知識も持っているしコードもちゃんと書ける。自分よりも。なので余計にタチが悪い。一人で開発するんならそれでいいのかもしれないけど。ちなみにバックエンドエンジニアはその上司自分だけ。

働き始めて2年も経たないペーペーだし、年も離れているし、どういうアプローチをすればいいかからないんだよね。職場文化(?)を変えるのはそれなりの労力がいるし、とっとと転職して自分環境を変えた方がいいかもな、と思っているけど、如何せん地方なので、あんまり職がない。

2017-11-29

ニコニコ動画(く)リリース失敗に寄せて

そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います

Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - Qiita

ドワンゴアカウントシステムScalaコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています

ドワンゴユーザーアカウント基盤は明らかに破綻しています10 年以上にわたりガラケー時代から今に至るまで多くの業務コードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います

ニコニコ生放送におけるdockerの活用事例:dwango エンジニア ブロマガ:ドワンゴ研究開発チャンネル(ドワンゴエンジニア) - ニコニコチャンネル:生活

ニコニコ生放送(以下「生放送」)ではバックエンドフロントエンドサーバーを建てる環境として、2016年からDocker Swarm採用し始めています

Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができますさらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上ゼロコンフィグレーション)で実装たことは素晴らしいと思いますしかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。

私は kubernetes が嫌いです。 Google 製品開発者UX考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます

http://gihyo.jp/dev/serial/01/dwango-engineersoul/0002 大量トラフィックを支えるインフラ独自プロトコル,ファイルシステム実装もいとわない!~

実は分散ファイルシステム独自に開発しました。もともと既存オープンソースファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自調査開発を進めることにしました。

現状は初期バージョンの開発完了にかなり近づいています

こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって

  1. OSS分散ファイルシステム使用するという目論見が失敗した
  2. 自前の分散ファイルシステムは 9 カ月まえの時点で全く完成していない

ということが分かります

なぜ彼らはパブリッククラウドCDN を使わないのか?

触れない話: 事実上全然稼働しなかった CTO北の将軍様

パブリッククラウド特に CDN採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザー結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定理由をここでは探ってみます

ASCII.jp:niconico(く)開発の遅れを謝罪

動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています

ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しか現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。

CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性

大規模配信 | 強烈な価格競争 原価割れ総合サービス提供で収支合わせ)

要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴCDN流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います

ただしこの点において今後もビジネス環境技術環境現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。

まとめ

まあもう無理でしょいろいろ

2017-11-05

Webフレームワーク選定の悩み

Webアプリを作るとき何を基準にしてプログラム言語Webフレームワークミドルウェアを選定していますか?

RailsCoC:convention over configuration)以外の手法活用して、開発を高速化するにはどうすれば良いでしょうか?

 

希望条件

  1. 素早いプロトタイピングscaffold機能など
  2. テストコスト削減:関数型プログラミングモジュール手法
  3. 性能:コンパイル型の言語

…こういう条件を備えていれば良いかな?

 

フロントエンド

  1. JSGUI作成Vue.js等のSPAフレームワーク

 

バックエンド

  1. データ永続化ストレージCRUD機能を用意できれば何でも良い?

 

試作

  1. Railsプロトタイプを作りデザインスプリント実践

 

本番

  1. 形が決まったらGolangGCPで作り直して本番投入

プロトタイプを作り直す手間を省きたい。プロトタイプと本番を同じツールで作りたい。)

 

サーバーAWSバックエンドElixir/Phoenixフロントエンド:Elmという組合せはあまり盛り上がっていないようなので、Rails代替手段は何が良いのか?気になります

2017-10-19

BASIC!のプログラミング教育適応性について

題:BASIC!のプログラミング教育適応性について

副題:Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

少し考えてみたのでまとめとして投稿します。

01.はじめに

この文章は、Androidで動くBASIC!でプログラミング教育を行うメリットデメリット

ついて記載しています

02.BASICとは

BASICプログラム初心者向け言語として1960年代に発表された古い言語です。

極めて簡単文法インタープリターによる即時実行や1970~80年代パソコン

無償で搭載されていたこから沢山の人に利用されていました。

しかし、簡単ゆえの機能の少なさと即時実行方式のための性能の低さやその後の

優れたプログラム言語発表によりBASICの利用は著しく低下しています

03.BASIC!とは

BASIC!はアンドロイドタブレットスマートフォン上で動くアプリです。

Google playからインストール可能無料で利用できます

BASIC!

https://play.google.com/store/apps/details?id=com.rfo.basic&hl=ja

BASIC文法踏襲していますが、Android向けに大幅に命令拡張されており、

GPS等の各種センサー情報取得やSQLiteデータベース機能WEBVIEWを利用

したHTMLCSSJS表示・実行など約500程度の命令群で構成されています

無料広告なしのアプリインストールするだけでこれらの機能が利用可能

インタープリターなのですぐに実行することもできます

04.BASIC!でプログラミング教育を行うメリット

メリットについては以下があげられます

a.BASICプログラミング知識を持つ人は以外と多い

 過去の栄光というかBASIC自体は広く利用された時期が過去存在パソコン

 だけでなくポケコンゲーム機等でも利用できました。

 BASIC!は基本はBASIC拡張であり文法変数の取り扱いにおおきな違いは

 ありません。

 その当時、少しであってもBASICを触った人は多いのでメンターとしての

 再教育は容易だと考えます

b.HTML,JS,CSS勉強継続してできる

 BASIC!は手続き型と呼ばれる非オブジェクト指向言語であり最新の言語

 とは異なっています

 BASIC!のネイティブ命令群だけだと他の言語へのスムーズな移行は難しい

 かもしれません。

 しかし、BASIC!にはHTML5アプリのようにBASIC!自体webViewでHTML,JS,CSS

 を動かすことができます。(HTMLモード

 HTML,JS,CSS現在Webの標準であり、進化を続けています

 特にjavascriptオブジェクト指向言語進化採用される領域フロント

 エンドからバックエンドまで広がっています

 

 BASIC!自体webViewは他のAndroidアプリ同様、chromiumベースAndroid

 システムWebviewの更新により常に最新化されています

 HTMLモードではjQuery,Angular,ReactなどのJSライブラリも利用できます

 最初BASIC!ネイティブプログラムHTMLモードJSを利用したプログラム

 とSTEPを踏んだ学習可能だと思います

c.インストール環境設定が容易

 前述の通りアプリインストールするだけで利用できます

 追加の課金プラグインなどは不要です。

 またAndroid2.3以降でインストール可能です。

 但しAndroid5.0あたりからAndroidシステムWebviewが導入されているので

 Android5.0以降の端末を選択する方が無難です。

 インストール後、環境設定をする必要もありません。

 端末のルート化も不要です。

d.Androidデバイス等が安価

 安いタブレットであれば1万円程度で新品が買えます中古スマホであれば

 更に安価です。

 またプログラムを作るのでキーボードもあった方がいいと思います

 キーボードも2~3千円程度で安価です。

 もちろんソフトウェアキーボードフリック入力など)でもプログラム

 作れます

 パソコンよりもはるか安価プログラミング教育が実現可能です。

e.子供Androidデバイスに慣れている

 iPhoneの登場以来現在の子供たちはタッチパネルAndroidデバイス

 慣れています

 通常のノートパソコンに比べ違和感は少ないと思います

 また教える大人側も日頃パソコンよりスマホを触る人は多いと思います

 教える側の負担も小さいのではないかと考えています

f.可搬性が高い

 ここで述べる可搬性とは別のデバイスで同じプログラムを動かす場合

 容易さの事です。

 BASIC!はインタープリタなのでソースファイルのみを別のデバイス

 SDカード経由等でコピーすれば基本的には動作します。

 仮にHTMLモード場合は併せてHTML,JS,CSSコピーするだけです。

 別のデバイスにはBASIC!さえインストールされていれば動きます

 BASIC!独自プラグイン拡張モジュールなどは特にありません。

05.BASIC!でプログラミング教育を行うデメリット

メリットだけでなくデメリットもあります。以下の通りです。 

a.性能上の問題

 BASIC!の実体Javaで出来ています。すなわちJavaよりは性能は悪い

 ことになります

 実際、大量の繰り返しや大量の文字列を扱うプログラムは性能が出ないので

 処理に時間がかかります

 Androidスマホタブレット自体パソコン演算能力には劣ります

 大量の実験データ演算するような教育には向いていません。

 但し、プログラミング教育には大きな障害にならないと思います

b.BASIC!自体の仕組みの問題

 BASIC!はプログラムを作るアプリである以上当然文法エラーを実行時に

 表示する仕組みになっています

 ただ一部エラーチェックが甘い部分もあり本来エラーとすべきところを

 そのまま実行する場合もあり想定外の結果となる可能性もあります

 次にエディタは単なるテキストエディタと同等の機能しかなく最近

 エディタにあるようなシンタクスハイライト入力補完といった機能

 ありません。

 ただ比較シンプルプログラムを作る教育では大きな影響は無いと

 考えています

c.一部機能に制約がある

 前述の通りHTMLモードではJSが動かせます。ただし制約があります

 JSローカルモードで実行されるという事です。

 非同期通信などを行おうする場合JSが実行時エラーになる可能性が

 あります

 またデータベース機能であるSQLiteへの操作についても文字型項目しか

 利用できない制約があります

 JSローカルモードのみなのは教育の事を考えると少し残念ですが

 それでも多くのフロントエンドJSは実行可能なので教育には

 使えるという理解でいます

d.参考となる文献がほぼない

 教育には教科書またはそれに準ずる書籍必要だと思います

 該当する書籍がないのが実情です。

 ただ1冊だけ日本語で書かれた電子書籍存在します。

 ■BASIC! ~ 分かりやすい教本で一から学べるコンピュータ言語 - AndroidSQUARE

 http://blog.livedoor.jp/an_square/archives/51887786.html

 BASIC!の文法自体は極めて簡単なのでどうにかなると思います

06.結論

上記の通り、メリット/デメリットを列挙してきました。

デメリットもあるものメリットの方が大きい印象です。

とくに教える側の負担が少ない点がメリットだと思います。 

 

2017-10-10

増田人達は開発で何の言語使ってんだろ

というか何言語使いの界隈がここに集まってるんだろう?

アプリバックエンドフロント??

日本語っていう答えはいらん

2017-09-12

エンジニアは優秀だけどデザイン台無しにしている

技術集団イメージあるけど、サービスがまじでイケてないって会社って結構あるよね。

バックエンドエンジニアが優秀でレスポンスがめちゃくちゃ速くたって、デザインが全てを台無しにするような。

インフラエンジニアが超高負荷に耐えうる環境を構築したところで、ユーザーからすれば知るところではない。

そんなことより、目の前のサービス大事なんだよ。

すなわち使いやすさだ。

楽天

楽天ってエンジニアは優秀な人がたくさん集まっているイメージがある。

でもあの楽天サイトの見栄えの悪さとデザインの酷さ。

絶対エンジニアデザインしてるだろ?

リクルート

リクルートもいろんなサービス持ってるし、エンジニアガチで優秀だ。

でもあのリクルート発のサービスUI/UXの糞っぷり。

クリックで済ませるべきところを7クリックくらい要求される導線、すさまじいユーザー経験だわ。

ヤフー

もうなんかCSSは微塵も使っていないかのような初代HTMLデザイン系。

昭和時代インターネットなんてなかったのは当然理解しているけど、昭和臭すら感じる。


あ、なんかギター侍って消えた芸人を思い出した。

2017-08-28

すべてのソーシャルゲームは、消えていく

日本ソーシャルゲームがヒットして、およそ10年経とうとしている。プラットフォームフィーチャーフォンからスマホへと移行したものの、相変わらず膨大な売り上げを生み出し続けている。この間、数多のタイトル作成され、そして消えていった。これはソシャゲ開発のお話である

ソーシャルゲームの開発は、他の業種同様企画から始まる。他社IPものであれば大手IPを扱う会社連携をとり会社主導で企画は進み、自社オリジナルタイトルであれば社内で抜擢されたプロデューサーとなる人物が中心となって企画を書き上げる。会社の規模にもよるが、小規模企業月商1億、大手なら月商10億を目指すことが目標だ。

その後、適任のデザイナープログラマー企画を含め5,6人があつまりプロトタイプ制作が始まる。ゲームシステムが組み込まれキービジュアルゲーム雰囲気を決めていく。最終的には会社からゴーサインをもらうことが目的となる。

プロトが通れば、次に、アルファ(一部動かないものの、一通り遊べる)・ベータ(ほぼ全機能実装)という順にマイルストーンが敷かれ、順に進めていく。多くのスタッフがこのアプリは月10億以上を売り上げ、ランキングで、モンストFGOといったアプリと並ぶことを意識して仕事をする。

最初問題はここで発生する。ソシャゲ企業Web前身なのだ。つまり判断する人間判断できないことが多い。唐突素人意見を繰り出したり、かのスティーブジョブスを真似てちゃぶ台返しを何度も行う。本人は真剣に、これが経営者のあるべき姿だと信じている。

このような妨害をかわしつつ、のらりくらりとベータへ進んでいくが、その辺りで作業者は厳しい現実と向き合うことになる。これは、微妙なんじゃないかと気づくのだ。その頃、手が空いてきたプロデューサーマーケターは呑気に広告計画を立てている。そして、いよいよローンチだ。多くの広告費が投入され、特設サイトや事前予約、プロモーションビデオが公開され、華々しい登場を飾る。多くのアプリはこのタイミングが一番ユーザ数が多く、売り上げも高い。逆にいえば、ここで数字が残せなかったアプリは早々に注意信号が点灯し、マーケターは顔を青くし、プロデューサポーカーフェイスとなる。ここでのユーザ数と売り上げは新しいタイトルに対する期待感広告費によって得られたもので、今後は開発したアプリの出来が問われていくことになる。使い勝手が悪い、バグが多い、サーバが止まる、ゲームがつまらない、思っていたものと違うなどといった理由で新しいユーザは次々と離脱していく。

そこで、いわゆる継続率という指標インストールした日から1日後、2日後、そして7日後、30日後に何パーセントユーザが残っているのかというデータ改善するため、マーケットや行動を調査し、どこにボトルネックがあるのかを調べ改善をするという動きが始まる。また、ユーザを飽きさせず定期的に課金してもらうため、運用が始まる。大抵新しく書き起こされた魅力的なキャラクターが、ローンチ時よりも魅力的な効果を纏って登場する。もちろんそれは、ガチャという形式提供され、最上位のキャラクターは数万程度の課金必要になるような確率で封入される。

さて、ローンチから3ヶ月が過ぎた。ここ最近ゲームは3ヶ月分程度の運用分を初期予算に組み込んでいるため、ここから実際に運用を続けるべきかどうかが真剣判断されることとなる。ところで、この業界での売り上げの方程式は、「DAU(日間アクティブユーザー数)xARPUユーザあたりの平均売り上げ額)」だ。問題ARPUだが、ゲームの人気度やガチャ確率によるものの、大抵のゲームは月を平均すれば10円〜50円程度となる。もちろん好調ガチャキャンペーンが当たっている場合、瞬間的に100円以上にもなる。これは、ユーザ数が少なくなれば作業に対する売り上げのうまみが減ることを示唆している。

ここで、運用の経費を概算してみよう。小さなゲームでも、10人〜20人程度は運用に携わっている。(大型タイトルだともっとだ)平均年棒500万円の給与として、月額41万円。ここで人件費の概算は+16%程度なので、一人47.5万円とする。20人で、約1000万円。さらサーバ代。ちょっとしたユーザ数でも数十台、数百台規模のAppサーババックエンドDBサーバリアルタイム通信サーバアセット用のデータストアや転送料金など、100万〜1000万程度を見ておこう。このサーバ代はなかなか癖があり、Appサーバ比較的増減がしやすものの、お金のかかるDBサーバは負荷を見越してシャーディングをがっつりかましたのにユーザが少ないと、簡単スケールダウンできず、泣く泣く無駄費用を払うことになる。もちろん、甘く見ていてメンテ祭りというのもよくあるが、基本的には事前に過剰な負荷分散が行われているパターンが多い。なにせ、月に10億も稼ぐんだから。 忘れてはいけないのは外注費。イラスト代、3Dモデル代、などなど。5人月 400万円としよう。

さて、サーバ台を500万として1900万が最低の運営費用だ。盛り下がってきたゲームARPU10円程度になるとして、元を取るためのユーザ数は約63,000人である。もちろんキャンペーンなどで一時的に売り上げが増えるので、もう少し少なくても良いかもしれない。いずれにせよ、今人気のあるタイトルもそうでないタイトルも、徐々にユーザが減ることで売り上げは減り、投入した資金から得られるリターンが減り、人件費サーバ代だけが重くのしかかる。

この時、開発の現場はというと、案外淡々仕事が進められている。慌てふためくのは上位陣のみで、末端作業者は細かな作業改善をしたり、次の異動先に思いを馳せたり、技術向上に努めたりする。また、会社に愛想をつかして退職するのも大抵このタイミングだろう。

その後徐々に、開発の人員が減らされていき、改善のサイクルが長くなり、キャンペーンの頻度も下がる。作業者のやる気はこの辺りで地に落ち、惰性での仕事が続く。当然ユーザからメッセージには平謝りの状況が続く。何度か、大きめのリリース広告を放つこともあるが、一度沈み始めた船はなかなか浮上することはない。そして、ある程度の利益を食い潰した(もしくは赤字に耐えられなくなる)ところで、いよいよ赤信号が現示される。

サービスを終了せよ」

この時、開発チームに余力など残っていない。決められた期日までにきちんとたたみ終わることが目標である開発者はこのプロジェクトを終わらせることができホッとすると同時に、できればなんらかの形で残したいと思うかもしれない。しかし、それは叶わないことが目に見えているのだ。昨今のアプリローカル側、つまりスマホにあるゲーム部分は結果を受け取る・ゲームプレイする、素材を指定するといった入出力の機能しかなく、主なシステムロジック、つまり実際にガチャを引いたり、素材を手に入れたり、結果を処理したりするのはサーバ側に実装されている。このため、ローカル側に全てを実装するのはサーバ側の機能フルスクラッチをするのと変わらず、とてもこんなことをする暇はない。また、昨今クラウドの様々なプロダクトを組み合わせて実装しているものも多く、素直にソースコードを書き直せば実装できるといった類いのものでもない。

そうして、ユーザ開発者それぞれが複雑な気持ちを抱いたままソーシャルゲーム消失する。

稀にあまりあるほどの利益を稼ぎ出したアプリであれば、ストーリーイラストアーカイブ配信される幸運な例もある。これは開発者経営側のプライド感謝人件費の消化であり、非常にラッキーなケースだ。

しかし、いずれにしてもゲーム自体が残ることはないのだ。

開発者でさえゲームを起動することはおよそ叶わない。なぜなら、複雑なサーバ構成再現せねばならないからだ。せいぜいデバッグ機能でバトルやUIをちょこっと動かすぐらいしか出来ない。

これがソシャゲのあらましである。いま流行りのあのゲームもこのゲームも、いずれは幕が降りるのであるソーシャルゲーム時代とともに人の心の中へと消えていくのだ。

2017-08-14

web系の専門用語多すぎ問題

門外漢からするとこんな風に聞こえてる。(所々適当に書いてるし書いてる内容は嘘デタラメ

「gulpでbowerしてsassgruntビルドすれば、cssストリーミング形式でデタッチされるから便利だよ。それにgulpはCoffeScriptとかtypescriptみたいな流行りのサードパーティも従来のJSみたいに変換してくれるしウォータフォールじゃなくてアジャイル的なプロジェクトでも使いやすい。スクラッチから書かなくてもいい感じにアジャストしてくれるよ。あと、OSSとしてgit上に上がってるんだけど、DLなんかもAWS連携させてWebGLTensorflowやらchainerやらと組み合わせればブラウザDQNとかA3CとかDCGANも動かせるスクリプトリリースされてた、バックエンドではDNNを走らせてフロントで表示する分をNode.jsカスタマイズしたりタスクランナープロセスマネージメントできるからもはやjstensorflowを含めたpythonラッパーみたいな感じで使えて便利。最近ではbluemixがBitcoinマインングをサポートしていてブラウザ上でウォレットからマイニングセットアップまでできるんだってブロックチェーンの仕組みを拡張して社内のタスクマネージャーとかNAS上のデータ分散してサーバーに保存できるみたいなこともあるんだって。」

どうしてweb系は専門用語肥大化するんだ。

2017-08-06

https://anond.hatelabo.jp/20170806183053

こういう議論を見て良く思うことは、「できるエンジニア」「優秀なエンジニア」って何をもって判別されるんだろうということ。

EmacsVimの便利な設定ファイルが書けること?

一人でRailsJSWebフロントエンドバックエンドを書けること?

業務系のシステムの開発経験

競技プログラミングの腕前?

マイコンみたいな、IoT組み込み開発ができること?

それとも解析や最近流行りのAIの仕組みを把握してる的なこと?

2017-08-05

また新システムかよ

http://anond.hatelabo.jp/20170506031453

↑の元増田です。

一応自分属性を書いておくと

といわけで、今度のイベも「うわーマジだりー」という感じだったり。

そこに来て「バックエンドシステム???

名前からして意味不明だし、新システムとか要らないんだけど。

追記

ブコメに新三川艦隊任務の話があったけど、あれは他の枝で書いた通りこの前クリアした。

クリア時の編成と装備はこんな感じ

まあでもかなりしんどかった。今でも思い出すたび不快になる。敵戦艦攻撃が一発でも当たれば即撤退ないしボスS勝利が消えるとか、闇深すぎ。

上に書いたように支援艦隊も使えず、ひたすら試行回数を稼ぐしかなかったので、バケツ50~60個は消えたと思う。

はてなー三国志 二面外交

上:DeNAのWELQ問題、最大の原因とされている責任者「村田マリ」とは何者なのか? - GIGAZINE

下:横山光輝三国志 画像検索

b:id:qtamaki

淡々としているが記者の憤りを感じる

お。リリースされたか

b:id:fatmonger

殺しにかかってるっていうけどこの人十分稼いだでしょ。周りの目を気にするならあん仕事しないだろうし、むしろ引退できてせいせいしてたり?

光輝「いらすとやもまだまだよのう」

b:id:exadit

経営からすれば執行責任経営責任は別という事なのかな。でも、社内でちゃんとそれなりの対処はされると思いますけれど。

そのままどこにでも持っていけそう。すげーなこれ。

b:id:mcgomez

私怨含みっぽい。

失くすには惜しい出来だ…

b:id:miz999

こういうインチキ臭い業界で成り上がるには、大学生の頃からその大学生ブランドを最大限に活かしてメディア企業に媚びて取り入るところから戦いは始まってるんだな。言いたくないけど電通東大生女子にしてもあれだし

GoogleOCRってこんな強いのか

b:id:nice_and_easy

批判対象がコト(事件)やモノ(仕組み)からヒト(犯人)に移るとにじみ出る末期感たるや

呂布だー!

b:id:kei_1010

これに関わってた奴は全員が100%モラルハザードだという事を理解してる。ってか理解できないやつはさすがにトップクラスITベンチャーで勤められない。 つまり村田上司も部下も全員故意犯。彼らに倫理観は無い。

存在する全ての漫画で、これできて欲しい。

b:id:hiroshe

こういう仕事してると、結局そういうふうになっちゃうのかなあ。

最高かよ

b:id:lbtmplz

IT企業=悪人という認識世間に広めた功績を認めよう。我々はまた技術インターネットから遠ざかった…

最高だった

b:id:elephantskinhead

昔の隊長みたいなエントリやな

孔明の罠検索したら4つ別の画像がちゃんと出てきて草

b:id:paradisemaker

こういう「私たちイケてる」感で集まった人がやってたことが、結局は「検索結果にゴミをばらまくこと」だった、というのはコミュニティとして考える必要があると思う

これ、企画からフロントバックエンドまで全部レベル高くて凄いな。漫画プラットフォーム作ってるところ、まるごと買ったほうがいいんじゃなかろうか

2017-07-28

Googleからってちやほやするのもうやめたら

freeeの件で「Google出身メンバーが高度な技術を引っさげて日本バックエンド革命すべく起業したっていうなんとなくかっこいいストーリーほとんど唯一の売りだったのに」というブコメがあるが、そもそも役員プロフィールを見ると、彼らは単に営業担当であったことがわかる。

https://corp.freee.co.jp/company/

Google在籍経験のあるメンバー担当職務は、「中小企業向けのマーケティング」、「新規顧客開発」、「ビジネス開発」などで「エンジニアリング」と書いてあるものは一人もいない。

当然ながら彼らに技術があるわけではなく、CTOは非Google。彼らはGoogleをやめて創業するにもかかわらずエンジニアリングからは一人も引っ張ってこれなかった訳だ。

そのへんを無視して「元Googleから」といってちやほやするのはもうやめた方がいい。あの会社ですごいのはエンジニアリングであって営業じゃない。

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