「インターフェース」を含む日記 RSS

はてなキーワード: インターフェースとは

2017-03-02

LINE世界で負け続ける理由は、ニュースタブのことじゃねえよ、馬鹿

http://blogos.com/article/212112/

----------------------------

僕はLINEを愛してる。

愛してるがゆえにLINEをどんどん駄目にするLINE経営層が許せない。

はっきり言うが、彼らのやってることはグダグダだ。他社のチャットサービスが成長してる中、LINEが初めてユーザー数が減少したと言うがそれは当然だ。

説明しよう。

----------------------------

微妙にバズっているこの記事

多分に自己愛思い込みの強い著者が、アプリってのはこうグロースさせるもんなんだからそれをやれてないお前ら間違っている

一方的断じているもので、共感できるところは各タブに名前が入っていないことくらいのぶっちゃけ大して価値のない記事であった。


そもそもニュース領域twitterと違い、LINE株式会社側にLivedoor由来の編集チームがいてリソースが確保されている点、すでにLINENEWSという

基盤が存在している点で突然何の前触れもなくニュースを始めた日本twitterとはわけが違うだろう。


さら噴飯ものタイムラインについての評価で、まず誰も見ていないと断じているが、

リサーチベースではこんなものも出ている(http://gaiax-socialmedialab.jp/post-1891/

大体、広告事業としてのLINE ADS Platformは、このタイムラインベースにしたインフィードアドが中心であり、それで十分にマネタイズできている

ということは、タイムライン一定使われていて、広告インプ一定以上発生していることの証左だろう。


まり、この著者自体が、自分の見ている物事からしか評価判断のできない典型的な「マーケティング知らない人間なのだろう。

何をしてきた方かは存じ上げないが、いわゆるユーザーグロースのみをマーケティングであると思い込んでいるIT野郎


LINEニュースタブは、すでにユーザー一定以上グロースしている国内LINEユーザーに対してより多くの広告インプを発生させるためのレベニューグロース

としての側面が強いわけで、それも含めてマーケティングであるのだから、十分LINE現場も、経営陣もマーケティングを、経営理解していると言っていいだろう。


あ、後ユーザー数が減少と書いているけど、これはニュースタブを追加していない国についての話であって、そもそもの前提からしてもうめちゃくちゃ。調べずに書いてる感満載。




からこそ失望したのが、これなわけで。僕もLINEを愛しているけど、これはマジでないんじゃないか

http://jp.techcrunch.com/2017/03/02/line-clova/

----------------------------

スペインバルセロナで開催中のモバイルカンファレンスMobile World Congress(MWC) 2017」。そのキーノートにも登壇したLINE3月2日クラウドAIプラットフォーム「Clova(クローバ)」を発表した。

今後はClovaを搭載したアプリ「Clova App」を提供するほか、初の自社デバイスとなるスマートスピーカーWAVEウェーブ)」を今夏にも日本韓国で発売する予定だ。

今冬にはスマートディスプレイ「FACE(フェース)」の提供も控えるという。

----------------------------


要はAmazon Echoとか、Google Homeとか、スマートスピーカー領域(というか、音声会話をベースにしたインターフェース領域)に打って出るというわけだ。

これは一面ではすごく合理的に見える。つまりチャットサービスとしてユーザー間、ユーザー企業間でのコミュニケーションインフラ提供しているLINEが、textingから音声を介した

コミュニケーションインフラに舵を切るということ。事業の成長の向く先としてわかりやすい。


が。これ。マジで間違いなくうまくいかない。頓挫する。てかこれこそ、挑戦の美名に酔いしれてマーケティングを忘れた経営判断だろ、と思う。


何が問題か。答えは明白だ。 言語である

音声インターフェイスの要は、自然言語処理であり、発話された音声を正確に理解する技術にあるはずだ。

この点、AmazonGoogle基本的に「英語」という話者が圧倒的に多い言語に優先して開発を進めればよかった。現に英語自然言語処理はめちゃくちゃ進んでいる。


しかし、LINEは違う。英語圏ではまったく使われていないサービスなのだ。それどころか、LINEが浸透している主要国は日本台湾タイインドネシアの4カ国である

もうおわかりだろう。どの国も公用語がバラバなのだ


サービスを普及させるためには、地の利を生かすほかない。そういう意味英語圏は端から勝負しようがない。一方中華圏、圧倒的人口を誇るメインランドにはWeChatという

巨人存在し、市場に入ることすらできていない。


であるからして、浸透している主要4カ国で普及させる、という選択肢にせざるを得ないだろう。しかし、この4カ国ぶっちゃけ日本インドネシアしか1億を越える人口の国はない。

その上、GDPベースで考えてもスマートスピーカー短期的に人口膾炙するほど普及させられるマーケット日本と台湾しかない。

さらさらに、R&Dの視点からいって、4カ国それぞれの言語にあわせて自然言語処理一定水準まで高めるには、英語1つに絞って開発するのと比較して単純に4倍のコストと労力がかかる。

典型的な、労多くして実り少ない状況なわけだ。


どう考えても八方塞だ。

コミュニケーションプラットフォームである以上「言語」は避けて通れない問題。これを攻略する方法は正直、僕にはわからない。



からもはやLINEは、チャットサービスとして浸透している国の中で、その土台の上で、ニュースタブとかその他もろもろで、

きちんとレベニューグロースを続けるのであれば、ぜんぜん負け続けることなんてないのになーと僕は思います

事実世界でこんなに儲けているメッセージングアプリはないのだから、その時点で十分世界で勝ってんじゃん、と思うわけで。

経営陣には、熱病に浮かされることなく、着実に一つ一つできることを勝負して行っていただきたい、そう思う限りです。

2017-02-09

ソシャゲゲームとしての底が浅くなるようにできている

ソシャゲタッチパネル操作という足かせのせいで、ゲーム性を追求することができない

あのインターフェースではオート操作主体MMOもどき関の山

まともなアクションゲームを作る事はできない

ちなみにユーザーの傾向として、ゲーム性よりもキャラクターの大量投入を望んでいる側面が大きいことも追記しておく

2017-01-09

最高の無料メールクライアント2017

GmailOutlookのようなウェブメールサービスを利用すれば、すべてのデバイス簡単メールアクセスモバイルアプリ提供できますが、それらのメールサービスあなたデスクトップでの動作保証するでしょうか? 

今は、多くの人が複数メールアカウントを持っている。これらのアカウントが異なるプロバイダ使用している場合は、一度に複数ブラウザタブを開く必要があります

便利な場所にすべてのメッセージを集約するだけでなく、優れた電子メールクライアントは、暗号化カレンダーRSSフィードVoIPアプリケーションとの統合などの機能を追加できます

デスクトップクライアントメールローカルに保存することもできるため、オフラインときアーカイブされたメッセージアクセスしたり、貴重なバックアップ提供することができます


eMクライアント

さまざまな電子メールプロバイダ統合されたチャットサポートする最高の電子メールクライアント

eM Client10年近く前から始まっています。その長い開発により、Windows用の最高の電子メールクライアントに発展することができたんや。

無料版は非営利目的使用と2つの電子メールアカウント限定されますが、それ以外の場合は有料版とおんなじ。

eM Clientには、GmailExchangeiCloudおよびOutlook.comタッチコントロール、高速検索統合カレンダーおよび連絡先のサポートが含まれてん。JabberGoogle Chatなどの一般的な標準をサポートする統合されたチャットアプリもあり、Outlookのような重量のあるアプリには良い選択肢ですわ。


Mailbird Lite

あなたメッセージを補う機能が満載されたすばらしいメールクライアント

Mailbird Liteは単なる電子メールアプリではなく、スケジューリングチャットファイル同期、チームワークのためのアプリケーションを追加できるコミュニケーションプラットフォーム全体です。

Mailbirdをダウンロードした後は、Proバージョンの30日間試用版に対処されます。このバージョンは、月末にアップグレードしないことを選択した場合限定Light Editionにダウングレードされますフリークライアントには時間制限はありません。

無料ユーザーは、速読電子メールスヌーズ添付ファイルのクイックプレビューなどの機能を忘れていますが、Mailbird Liteは依然として優れた選択肢です。最大3つの電子メールアカウントサポートし、スピードに合わせて最適化され、起動時に最適です。

セットアップ簡単です。電子メールの詳細を入力すると、Mailbird Lite必要POPまたはIMAPの設定を自動的に見つけ、メッセージインポートを開始します。あなたFacebookアカウント接続することができるので、あなたの連絡先のプロフィール写真あなたの受信トレイ活性化し、WhatsappGoogleカレンダー無料タスクマネージャMoo.do、teamworking app Asanaにリンクすることもできます


Claws Mail

Claws Mailのシンプルインターフェースは、より自信を持ったユーザーに適した強力な電子メールツールです

Claws Mailは使いにくくはありませんが、独自メールフィルタリングに耐え、無制限電子メールアカウントサポートしたい経験豊富ユーザーに最適です。

ここの他のクライアントとは異なり、ClawsはユーザーPOP3 / IMAP設定を手動で設定する必要がありますGmail使用している場合は、Googleアカウントの設定を調整して、安全性の低いアプリケーションアクセス許可する必要があります

古くは現代電子メールクライアントでは、HTMLメッセージ送信するオプションはありません.Clawはプレーンテキストのみですが、不要機能を省略することで、Clawは驚異的なスピード動作します。その検索機能特に優れており、プラグイン経由でも拡張できます

それは最も美しい電子メールアプリケーションではありませんが、Clawsはあなたスタイルを超えて物質評価するならば、素晴らしい自由選択です。定期的に更新されているため、バグはすぐに除かれます


Inky

すべてのデバイスメール管理するためのワンタイム設定の無料メールクライアント

Inkyの無料版はWindowsMac OS X、およびAndroidで利用でき、ワンタイム設定は3つのプラットフォームすべてで使用するのに最適なメールクライアントになります! 

電子メールクライアントダウンロードしてインストールしたら、Inkyアカウント作成するよう求められます。これにより、すべての電子メールアドレスリンクされ、POPおよびIMAP設定を設定することなく、Inkyがインストールされた任意デバイスからアクセスできるんです! 

一度登録すればセットアップ簡単カンタン♪ 各アカウントユーザー名とパスワード入力すると、残りの部分をInkyが処理してくれちゃう

日常的に使用されるInkyは優れた自動タグ機能メッセージタイプ個人定期購読ソーシャルノートなど)のインテリジェントなフィルタリングデバイス間の非常に高速な検索クラウド同期でわんだふるん♪。

Windows 7以降を使用していて、特定メッセージスレッドを見つけようと多くの時間を費やしている場合、Inkyは膨大な時間節約できちゃうの!


Opera Mail

優れたOperaウェブブラウザの背後にあるチームからの柔軟なオープンソース電子メールクライアント

Opera開発者は、電子メールを常に優れたブラウザ重要機能とみなし、無料電子メールクライアントであるOpera Mailの開発に多大な努力を払ってきました。

その機能には、メッセージテンプレート特に業務用に便利)、メッセージフィルタリングソートタイプ別メッセージソート、さまざまなカスタマイズオプションがあります

クライアントRSSフィードインポートするので、Feedlyや欠けているGoogleリーダーなどのWebアプリケーションの代わりになります


Thunderbird

Mozillaから期待されるように、たくさんの機能があり、無料拡張機能を利用することもできます

Firefoxと同様に、無料電子メールクライアントThunderbirdMozilla Foundationによって作成されました(しかし、2つの開発はそれ以来分離されています)。 ウェブブラウザと同様に、その機能は、サードパーティアドオンの膨大な範囲拡張され、強化されます

優れたビルトイン機能には、電子メールには大きすぎるファイルと、電子メールと一緒にRSSニュースフィードを読む機能があります

セットアップ簡単です。 ほとんどの現代電子メールクライアントと同じように、必要なのはあなたユーザー名とパスワードだけで、Thunderbirdは残りのものを処理します。


Windows Liveメール

長い時を経てもまだ選択肢に残る老舗の電子メールクライアント

Windows Live Mailは、Windows 8および10のMailアプリケーションに取って代わられた2012年最後更新されました。ただし、Live Mailの比較昔ながらの外観にもかかわらず、2つのプログラムはほぼ同じです。

Windows Live Mailは、私たちを含む多くの電子メールユーザーがより現代的ですが、最小限のデザインを好む3ペインレイアウト提供します。 RSSクラウドベース電子メールPOP3サポートし、添付ファイル送信したり、複数アカウント作業したりすることが容易になります

マイクロソフトのやり方が気に入っても、ウルトラスリムWindows 10アプリケーションがあまりにも制限されているのを見つけたら、従来のWindows Live Mailは賢明選択肢です。

 

 *

 

http://www.techradar.com/news/the-best-free-email-client

2017-01-06

2ちゃんねるマジで知名度無くなってきた

http://anond.hatelabo.jp/20170106223846

今の中高生から20代前半の奴らは、「2ちゃんねる」という言葉すら知らない奴がマジで多い。

2ちゃんねる知ってる」という奴は、2ちゃんねるまとめブログのことを指していて、「2ちゃんねる」という掲示板があることは知らない。

本家本元の2ちゃんねるを見せても、その前時代的なインターフェースに「なにこれ?どうやって見るの?」って感じ。書き込み方もわからない。

2ちゃんねるは、マジでオッサンしか利用してないんだなというのを実感した。

最近2ちゃんねる知らないどころか、ニコニコ動画知らないってやつが増えてきた。

2年前までは猫も杓子も初音ミク初音ミクと騒いでいて、

カラオケ行って履歴を見ればほぼ初音ミクの曲で埋まっていたのに

最近カラオケ履歴初音ミク名前を見ることは無くなった。

こないだ高3の女の子と会話したら、「私アニメオタクなんですー」って言うから

ニコニコ動画見てるの?」って聞いたら「なんですかそれ?」って言われて、

初音ミク好きなの?」って聞いたら「ボカロとかもうオワコンです。ダサいです。」って言われた。

今の女子高生初音ミクは知ってても、ニコニコ動画は知らないというのが多い。

ひろゆきビジネス時代遅れになってきてる。

2017-01-03

http://anond.hatelabo.jp/20170103000627

それ国内市場の話であって世界市場の話ではないよね。ビデオゲームはこれまでに無いくらいに盛り上がってるしOverwatchを始めとして豊作と言われた2016年を前にして何を言ったんだとしか

VRに関してはまだ始まってすらいね市場に対して分析が雑すぎる。2007年iPhoneガラケーインターフェースが違うので流行らないとか言ってた産経新聞並に雑な分析だと思う。

まあ一言で言うと観測範囲ますぎ。

2016-12-20

互助会って言われるブクマコメントってさ

記事に対するコメントじゃなくて人に対するコメントから面白くないんだよな。

人にコメントしたいならブクマじゃなくて記事コメント用のインターフェースがあるんだからそっちでやれよ。

PV寄与してあげたいかコメントじゃなくてブクマするって言うならその繋がりは互助会って呼ばれてもしょうがないし、その行為スパムと変わらないよ。

2016-12-19

Oracle案件に当たりなし説

もちろんスペシャリストがきちんとわかった上でOracleを使ってる案件大丈夫なんだろうが、中小規模案件Oracle使ってるのにろくなのがない。

Oracle案件ありがちなこと。

データベースは当然のごとく正規化されてない。昔はされていたのかもしれない。

使用されていない予約されたカラムの山。必須でない情報でもカラムを作るのでテーブルがどんどん肥大化していく。

業務必要リレーション崩壊している。

・謎のインデックスが大量にあるが、パフォーマンス上本当に必要インデックスはない。

・ストアドプロシージャが秘伝のタレ化。そのせいでOracleから抜けられない。

Oracleを使うとDB設計者の脳は破壊されるのだろうか。脳が破壊されているかOracleを使うのだろうか。

開発環境準備するのも面倒だしインターフェースダサいし、もうOracleが絡む案件やりたくない。

2016-12-10

Shadowverseはhearthstoneをどうパクったのか教えてあげよう

http://altavista.hateblo.jp/entry/2016/12/10/003830

実際両方やってたらシャドバがハースストーンをパクったかどうかなんて恥ずかしくて声に出せないレベルなんだが、どうやらわかってない連中がいるので。

なお、ハースストーンMTGをパクったが、それはカードゲームという概念をパクったという意味であり、各種システムをパクったシャドバとは同列に扱わない。

1マナスタートし、10マナストップする

偉大なるMTGが編み出したマナ・色マナ概念は豊かなゲームプレイの元とはなるが、土地事故あぼーんの元でもある。

ハースストーンでは毎ターン1マナずつマナ自動で増加し、10マナまで増え続ける事で序盤の小競り合いか10ターン目付近で巨大クリーチャー(または呪文)により決着をつけるという分かりやすゲーム展開を生み出した。

攻撃中・対戦相手は見てるだけ。

プレイヤーのターン中、対戦相手操作によって盤面に干渉する手段は無い。お互いのやり取りを楽しむという意味では攻撃指定・防御指定妨害呪文等を行使できればプレイの幅は広がるが、どうしても対戦時間の延長につながる。思い切って防御側は何も行動できない仕様となっている。

時間制限

各ターンの持ち時間比較的少なく、時間切れが迫るとアニメーションによって、切羽つまった感じとなる。

ハースストーン=導火線に着火

シャドバ=ターン終了ボタンが爆発?

ゴールデンカードヌルヌル動く

これはそのまんま。

(追記:同じカードの中でもレアキラカードがある。キラカードは性能は全く変わらないが他のカードが止め絵なのに対し、髪がなびいたりヨダレが垂れたり部分的アニメーション演出がされている。)

操作方法

ハースストーンやってたらシャドバのチュートリアル不要なほど同じ。ほんと同じ。ボタンの配置や操作性とかもうほんとまじで。恥ずかしくないの?

アリーナ

シャドバにアリーナなんて無くても良さそうだがわざわざつけた。

その他イロイ

途中で書いてて飽きて来たけど、やってたらわかるとしか言い様がないほどパクってる。

シャドバの開発者ハースストーンをどう和風に再構築するか?をベースに開発したのは間違いない。(ハースストーンMTGを再構築したのでは無く、デジタルカードゲームを再構築した。)

結果として、分かりやすインターフェースダイナミックな試合展開(ランダム性を意図的排除し、強コンボによる爽快な戦い)+ログインボーナス・萌絵等、良いゲームとなっているが、シャドバがハースストーンインターフェースを丸パクリしたこととそれはまた別の話。

12/11 19:30追記 飽きたって書いたけど、読んでくれた人が多いのでイロイロについて追記。蛇足なんて読まんでも可。

ヒーローシステム

プレヤー自身では無く、分身アバターであるヒーローが戦う。

ヒーローあくまで「戦士プリースト感謝します)」といった職業代表したキャラクターしか無く、課金して別の名前・顔・セリフに変更できる(着せかえなので性能は同一)。

敗北するとヒーローが爆発する。

固定セリフによる簡易チャット

ヒーロの顔を選択すると周囲180度に漫画のようにセリフアイコンが表示され、それを選択すると「挨拶感謝煽り感謝します)・反省」等のシンプルセリフを表示可能

カードが喋る

カードを出したときカード攻撃を受けたとき・死亡した等に、音声セリフなどが流れゲーム展開を盛り上げる(誰か怪我人はいませんか?)。

カード分解・生成システム

ダブって不要となったカードを使って、カードを生成出来る。コモンからレジェンドまで、生成出来ない限定カードは一切無い。

観戦システム

他人プレイしている様子を第三プレイヤーが観戦出来る。

盤面の背景が複数ありヌルヌル動いてる

ゲーム場の背景は戦場だったりダンジョンだったり、賑やかしとしてモンスターや森などが動いている。

言っとくけどシャドバはシャドバでいいところ沢山あるからね。

2016-10-18

http://anond.hatelabo.jp/20161018000810

よう、新入り。10年前の俺を見ているようだな。

俺も設計がやりたくてメーカーへ入ったら真っ先にテストをやらされた口だ。

すごくつまらない仕事で、毎日憂鬱だった。だが今から思えば得るものも多かった。

そんな俺からお前に日々の仕事を楽しくする2つのアイデアを贈る。耳の穴かっぽじってよく聞けよ。



I/Oプロになれ

電気回路が外部の他の回路とつながる部分。Input/Output。略してI/O

ここの評価は奥が深い。回路の中でも電源と並んでアナログ要素が非常に大きい箇所。

電子系の学科で習った回路理論現実世界リンクしていることが実感できるだろう。

さら最近のGHzを超えるような高速インターフェース評価ができるようになればいうことなし。

得難い人材として重宝されることは間違いないだろう。

経験を生かしてI/O周りの回路設計者に転身することも可能だ!



②測定装置プロになれ

製品試験に使うロジックテスタのマニュアルは読んでみただろうか?

そこにはテスタの動作ブロック図が載っていたりしないだろうか?

そのブロックから自分でテスタを作ることはできないだろうか?

頭の中だけでもいいから、Raspberry piのような組み込みPC秋月で売っている汎用ロジックICで同じようなものは作れないか考えてみよう。

テスタの原理が深く理解できるようになって同期に差をつけられるぞ。

2016-08-31

日本て室内なのにノートPC仕事してる人多すぎない?

ノートPCには漏れなく安物の液晶キーボードがついている。

無駄に疲れるし作業しにくいし絶対効率落としてるぞ。ヒューマンインターフェースには金かけろ。

2016-08-05

ルンバがすごいのは掃除でもセンサーによる空間認識でもない

http://ascii.jp/elem/000/001/206/1206225/

ルンバがすごいのは表情だ。

掃除を始めるときは「ティルー↑トゥルル!」といって頑張るぞーという雰囲気の音を出す。

掃除が終わってドックに戻った時は「トゥルルテッテレー!」と喜ぶような。

ルンバがすごいのはロボットらしい感情表現を足したことだと思う。

愛玩目的でない、作業ロボットに表情を付け加えることで、すっと生活の中に入ってくる感じがする。

実際にルンバが壊れた時は、カスタマーセンターに「ウチのルンバくんを直してやってください」というようなまるで家族の一員のような扱いの問い合わせが来るそうだ。

表情のパターンは多くないが、それで十分。

ロボットらしい愛嬌を持ちながら掃除してくれるルンバにだから、たまに段差に落ちて動けなくなってたりしても許せる。

ミスをしても、機能が至らなくても、愛嬌があれば許せる。

そういうインターフェースを(意図的か否かは置いておいて)作ったことがすごいと思う。

たまになにかのエラー人間の録音音声が流れるときちょっと悲しい。

2016-07-30

http://anond.hatelabo.jp/20160730155428

悪い、昼間っからビール飲みだしたから、もうよくわからん

それをそのままってのが意味がよくわからんけど、

newしてから渡せば良いと思うよ。

いちいちクラスに分ける理由は、こういう感じで、クラス内の変数アクセスすれば、画面事の表示とかが簡単に出来る的な?



EventHogeクラスクリックした時のイベント定義するクラス

      // Javaの書き方しらん、インターフェース実装することを定義したい

      public class EventHoge : View.OnClickListener {

        

        //画面事の名称

        public string ViewName = "";

        // Javaの書き方しらん、インターフェースメソッド実装することを定義したい

        public void View.OnClickListener.onClick(View v) {

            // 元増田サンプルそのまま ーー>

            AlertDialog.Builder dlg;

            dlg = new AlertDialog.Builder(MainActivity.this);

            dlg.setTitle("画面の名前:" + ViewName); // 画面名称が表示されるイメージ

            dlg.setMessage("Hello, サンプル!");

            dlg.show();

            //<ーー

       }

     }

MainHogeクラス(画面の初期化を行い、どのボタンにどのイベントを仕込むかを決めるクラス

    // Androidなにも知らんけど、元増田ボタンイベントを書く処理が書いてあるクラスのことが言いたい

    public class MainHoge {

        // そのメソッド

        public void Main() {

            //ボタン実装サンプル

            final Button button = new Button(this);

            button.setText("ダイアログの表示");

            View.OnClickListener ocl = new EventHoge();

            ocl.ViewName = "画面その一";

            button.setOnClickListener(ocl);

        }

    }




こんな感じにすれば、画面が二つあって、

その画面の名称を表示するようなボタンを、二つメソッドコピペして作らなくていい的な?

もうぶっちゃけ元増田が何を悩んでるのか、ようわからんわ。

サンプルは、出来るだけとっちらかさないよう、匿名クラスとか使って、サンプルで紹介したいところ「だけ」を書くんだよね。

から、そのサンプルがどういう意味かをちゃんと読み取って、自分ならこう書くとか、こう書けるか? とかを考えてこそ勉強だと思うよ?

今回のレイだと「View.OnClickListener」っていうインターフェイス実装したクラスを、setOnClickListenerすればいいってことさえわかれば、

匿名クラス?(っていうのかな? ちょっと用語はよくしらん、クラス定義を使い回さず、その場だけのクラス定義を書く書き方)とかを使わずに、

どういうふうに応用ができるか? とか頑張れ!

頑張れ!

頑張れ!

はああああああ。

おれはビールを飲む!

http://anond.hatelabo.jp/20160730125112

うーん?

いや、なんか、通じてないな。

もうちょいサンプル詳しく書くからサンプルのどこがわからいか言ってくれ。


EventHogeクラスクリックした時のイベント定義するクラス

      // Javaの書き方しらん、インターフェース実装することを定義したい

      public class EventHoge : View.OnClickListener {

        // Javaの書き方しらん、インターフェースメソッド実装することを定義したい

        public void View.OnClickListener.onClick(View v) {

            // 元増田サンプルそのまま ーー>

            AlertDialog.Builder dlg;

            dlg = new AlertDialog.Builder(MainActivity.this);

            dlg.setTitle("サンプル");

            dlg.setMessage("Hello, サンプル!");

            dlg.show();

            //<ーー

       }

     }



MainHogeクラス(画面の初期化を行い、どのボタンにどのイベントを仕込むかを決めるクラス

    // Androidなにも知らんけど、元増田ボタンイベントを書く処理が書いてあるクラスのことが言いたい

    public class MainHoge {

        // そのメソッド

        public void Main() {

            //ボタン実装サンプル

            final Button button = new Button(this);

            button.setText("ダイアログの表示");

            button.setOnClickListener(new EventHoge());

        }

    }




こうやって、クラス分けて書けば、外とか中とか、全く関係なくなるじゃん。

元増田サンプルだと、メインの中でインターフェース実装したクラス実装を書いてるから、中とか外とかがあるんじゃないのか?

自分クラスとして定義して、そっちで実装すれば、メインは紐づけるだけでよくなって、仮引数?の中で実装しなくてもすむじゃん。

http://anond.hatelabo.jp/20160730090832

よくわからん

中が嫌なら外でかきゃいいじゃん。

javaAndroidもしらんから適当だけど。



      // Javaの書き方しらん、インターフェース実装することを定義したい

      public class Hoge : View.OnClickListener {

        // Javaの書き方しらん、インターフェースメソッド実装することを定義したい

        public void View.OnClickListener.onClick(View v) {

            // 元増田サンプルそのまま ーー>

            AlertDialog.Builder dlg;

            dlg = new AlertDialog.Builder(MainActivity.this);

            dlg.setTitle("サンプル");

            dlg.setMessage("Hello, サンプル!");

            dlg.show();

            //<ーー

       }

     }

// メインスレッド的なところ

//ボタン実装サンプル

final Button button = new Button(this);

    button.setText("ダイアログの表示");

    button.setOnClickListener(new Hoge());



こう書けば、中で書かなくて良い気がするけど、駄目なの?

なんか、インターフェースから引数の中ってのが意味わからん

どう関係してるの?

2016-07-27

まあ今はクリエイティブクラウドで月5000円だけど(年間5万

昔は10万て高い

アドビソフトとかそれなりの動くPCとか買うのは高いよな

(3Dならなおさら

バンド楽器だけで3-5万だし、録音機材、編集のためのソフトインターフェース、見あうスペックPCとか

高いもんな

写真ならなおさら

金のかかる趣味以外は貧乏な人でもやってるって考えるのが普通だと思うよ

サッカーとか野球バットとかボール場所と人がいればできるかね

2016-07-22

ポケモンGOの先見性を見抜けなかった斜に構えた自分死ね

ベータテストプレイしたけどクソゲーだしインターフェースもだっさいしでこりゃはやらんわ任天堂やっちまったなと思ってしまった俺がにくい

2016-07-17

Excelに苦戦中

いわゆるExcel方眼紙システム設計書を書いているのだが、これがどうにも上手くいかない。

問題は色々あるが、大きく分けて「必要情報が見えにくい」「変化に追従するのが大変」に集約される。


まず「必要情報が見えにくい」について。

そのメソッド記述するのに必要な、他の設計書や仕様書を見つけにくい。

例えば、他の設計書(1ファイルで1クラス)に書かれているメソッド名や引数が合っていなくても、すぐに発見しづらい。

また、入出力情報が書かれたインターフェース仕様書を探しにくいなどなど。

そもそもどうユースケースを読んで、設計必要クラス抽出するかもよくわからないし。


次に「変化に追従するのが大変」について。

上述の状態設計書を書いた結果、製造するプログラマから「こんなんじゃ実装できない」と突っ返されて修正するパターンが多い。

また設計を進めた結果、仕様変更必要事態が度々発生する。

更に要件定義レベルでの見落としによる手直しも、結構な頻度で起きる。

いずれもExcelファイル1個に留まらない、影響範囲の大きい修正になるケースが殆ど

そんなことが相次いで発生した結果、修正対象抽出修正確認作業作業量が膨大化し、全く対応できない。


というわけで、もはや限界ギリギリだったり。

「1個ずつ解決していけばいずれ必ず終わる」を合言葉に、気合努力根性でやってきたけど、なんでこうも先が見えないのか意味がわからない。

どうしたら対応できるのか・・・

2016-07-15

http://anond.hatelabo.jp/20160715223351

https://www.microsoft.com/ja-jp/windows/windows-10-specifications

一応、↓の通りとはなっているけれど、たいていこういうのは最低限スペックから、この2倍あれば問題なし。

システム要件

CPU:1 ギガヘルツ (GHz) 以上のプロセッサまたは SoC

メモリ: 32 ビット版では 1 GB、64 ビット版では 2 GB

ハード ディスクの空き領域: 32 ビットOS では 16 GB、64 ビットOS では 20 GB

グラフィックス カード: DirectX 9 以上 (WDDM 1.0 ドライバー)

ディスプレイ (画面解像度): 800x600



仕事複数台使ってきて思うに、Win7810それぞれ、必要スペックはさほど変わらないよ。むしろ、8以降は7より早いんじゃないかと思うくらい。

はいえ、動かなくなるものも出てくるからCD化やバックアップ必須

モニタキーボードマウスといったインターフェース部分が使えることが確認できてからアップグレードする事を薦める。まぁ、普通は使えるんだけど、使えなかった時が痛手だから

2016-07-06

http://anond.hatelabo.jp/20160705224433

しつこくてすみません。(謝る気ないw)


なんか聞いてるとデータモデルをちゃんと押さえられていない気がします。

根底」にあるモデル(大抵の場合DBにいるやつ)を抑えていれば、それ以外のデータ構造はそれらの変換からできているので、世をしのぶ「仮の姿」ですよね。

根底」にあるやつがどんな風に変装して「仮の姿」になっているのかを調べて頭に入れて、ついでにメモっておけばOKですね。


インターフェース齟齬がでるのは、何が「根底」にある『変わらないやつ』で、何が世をしのぶ「仮の姿」(『いかようにも変わる』)なのか、

『変わらないやつ』からいかようにも変わるやつ』にどんな風に変身(変換)しているのかを整理できていないことが原因のような気がします。。

仮の姿から「別の仮の姿」へ変換するときも、『変わらないやつ』とそいつらがどんな風に変身した関係なのかを抑えてないと、変な設計になるのではないでしょうか?


要するに「仮の姿」と「別の仮の姿」だけで考えてはダメ!だと。

常に「根底」にある『変わらないやつ』を意識しろ!っていうことですね。


上から目線すみません。。


追記:

他人設計した「根底」にある『変わらないやつ』が残念なものだった場合は、なんとも言えないです。。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-06-11

IDEなしで開発してる人に聞きたい

コード内の関数呼び出しにマウス当てたらインターフェースポップアップしたりとか、クリックしたら別ファイルのその関数定義に飛んだりできるの?

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。


富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。


富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2016-05-17

http://anond.hatelabo.jp/20160517022608

>それをユーザから見て命令変数への破壊的代入ではなく参照透明な関数インターフェースで実現するのがいわゆるモナドや(誰かの独自解釈ではない本来の)FRP

はい、戯れ言への反論がkenokabeよりBlogでされました。

http://kenokabe-techwriting.blogspot.jp/2016/05/frp.html

http://anond.hatelabo.jp/20160516152330

それをユーザから見て命令変数への破壊的代入ではなく

参照透明な関数インターフェースで実現するのが

いわゆるモナドや(誰かの独自解釈ではない本来の)FRP

http://elm-lang.org/examples/time

view : Model -> Html Msg
view model =
  let
    angle =
      turns (Time.inMinutes model)

    handX =
      toString (50 + 40 * cos angle)

    handY =
      toString (50 + 40 * sin angle)
  in
    svg [ viewBox "0 0 100 100", width "300px" ]
      [ circle [ cx "50", cy "50", r "45", fill "#0B79CE" ] []
      , line [ x1 "50", y1 "50", x2 handX, y2 handY, stroke "#023963" ] []
      ]

HaskellライブラリもElmのような言語も、サンプルもJavaScript実装

ググればWikipediaで出てくるレベル

https://en.wikipedia.org/wiki/Functional_reactive_programming#Implementations

ログイン ユーザー登録
ようこそ ゲスト さん