「アーキテクチャ」を含む日記 RSS

はてなキーワード: アーキテクチャとは

2018-11-15

anond:20181115131830

読者と知識価値観の近い現代マインドファンタジー世界を描くというのに、

異世界転生(転移)以上にやりやすい題材がないからってのもデカいだろう。

ないでしょ、ここまで使いやすい始まり方って。

異世界転生以上にそういう形で使いやす汎用性の高いアーキテクチャ確立されたら流行るよきっと。

2018-10-23

増田プログラマー養成講座 その10 OOP参考書

前回はオブジェクト指向プログラミングOOP)の使いどころを学ぶために、MVCフレームワークを使ってみました。(ほんの触りだけ)

今回はOOP理解を助けるための参考書を探してみましょう。

 

OOP参考書

OOPに関する有名な本はたくさんありますAmazonレビュー評価が高い本は、定番の本が多いです。

だけど分厚い本は、ある程度プログラミングに慣れてから読んでみないと、最初意味チンプンカンプンだと思います

最初意味が分からなくても)なるべく早い時期に1回は読んでみた方が良いと思う本をピックアップしてみます

 

オブジェクト指向でなぜつくるのか 第2版

この本は、OOP概要、基礎知識コンパクトにまとめられています

今の自分知識の過不足をチェックできます

この本を1つの目安にして、今後の学習指針を立ててみて下さい。

 

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

https://www.shuwasystem.co.jp/products/7980html/4614.html

この本は、OOPも含むプログラム設計ノウハウ原則をまとめて紹介しています

カタログ的に、各テーマを広く浅く紹介してるだけなので、詳しい内容は個別に掘り下げる必要がありますが、それでも概要を知る上では役立ちます

今すぐ理解できなくても、「あー、そういえば、そういう話もあったな」と後で思い出せる程度に眺めておくだけでも十分だと思います

(第3章にある「UNIX哲学」は、初心者にとってプログラミングの良い指針になると思います。)

 

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

https://gihyo.jp/book/2016/978-4-7741-8361-9

この本は、上記2冊の内容を具体的な事例で説明しているような本です。

OOP解説本をいろいろ読んでみると、

などといった用語に出くわすと思います

これらの内容はそれぞれが1冊の本になるほどボリュームの多い内容ですが、本書ではそれらのエッセンスをうまくまとめていると思います

サンプルコードRuby説明されていますが、何らかのOOP言語を使ったことがあれば、Ruby文法を知らなくても、だいたい意味は分かると思います

 

プログラミング入門書を数冊読んだ程度の段階では、上記の本を読んでもいまいちピンと来なくて、意味理解できないと思われます

しかし、将来自分がぶち当たるであろう壁、課題を先取りしているつもりになって、「こんなことも考慮してるんだな!」と雰囲気だけでもつかんでもらえればいいんじゃないかと思います

 

プログラミングって難しいイメージがありますけど、習うより慣れろの精神で、とりあえず適当に触ってみるのがいいと思います

 

その他

PHPを使って、OOP基本的な仕組みを説明をしたので、PHP入門書を挙げるなら、とりあえずこの1冊。

自分にとっては分かりやす説明だと思うのですが、類書はたくさんあるので、実際に本屋で確かめてみましょう。

 

Java入門書文法の基礎を学んだら、次に読んでみたい本。

デザインパターン」という知識があると、他人が書いたプログラムを読むときに役立つと思います

(なんでこういう書き方をしてるんだろ?とか、定番の書き方=パターンがいくつかあるので。)

 

グチャグチャな汚いコードを綺麗にスッキリさせるノウハウがあります

リファクタリングに関する知識を学ぶと、プログラムの書き方が改善されて、後で自分メンテナンスするときに苦労が減ります

 

今の段階では、パッと思いついた本はこんなかんじだけど、他にも良い本はいっぱいあります

自分が分かりやすいと思う説明方法と、他人が分かりやすいと思う説明方法は、必ずしも一致してない場合が多々あります

図書館本屋で、実際に本の内容を確かめてみて、自分にとって一番分かりやすいと思える説明の本を探してみてください。

 

本のコストパフォーマンス

リファレンス文法辞書など)は、読む頻度が多ければ、買って損はしない=元は取れると思うので、自分への投資だと思って、必要な本は買うようにしましょう。

プログラミング専門学校かに行ったら、学費が何十万円もしますね?それを思えば本なら安いものです。)

 

プログラミング学習曲線

プログラミングに限らず、他の勉強でも同じだと思いますが、最初は知らないことの連続ですね?

プログラムサンプルコードを見ても、意味が分からなくて、中身が不明な「ブラックボックス」に見えると思います

でも、いったん意味が分かるようになると、霧が晴れたように、急激に視界が開けてきます

学習曲線で言えば、滑らかな右肩上がり(/)ではなく、ある時グイッと変わる階段状(_l ̄)の変化に近いと思います

なので、最初は分からないことが多く感じても、それが当たり前なので、あまり気にする必要はないです。

理解を早める補助として、上記のような参考書活用されてみて下さい。

 

まとめ

今回までで、手続言語構造プログラミングオブジェクト指向プログラミング)の基本を知りました。

次回は、問合型言語SQL)を学び、データベースを使いましょう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書 ←★今ここ★

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-22

増田プログラマー養成講座 その9 MVCフレームワーク

前回はオブジェクト指向プログラミングOOP)で使う様々な仕組みについて学びました。

今回はOOPWebアプリを作ってみよう!

 

今日学ぶこと

 

OOPの使いどころ

OOP文法を学んだ後、OOP長所が発揮される場面をどうやって説明したらいいのか?を考えてみた。

横田意見を参考にして、「フレームワーク」を使って、OOPの使い方を見てみよう。

 

フレームワークとは?

framework →「枠組み」「骨組み」「構造」などという意味英語

システム開発で使われる「フレームワーク」とは、よく使われる機能のパーツを用意して、まとめて1つのパッケージにしたプログラム群のことだ。

 

イメージとしては、いろんなおかずが入ってる豪華な幕の内弁当のようなものだ。

ただし、ご飯のマスだけが空になっていて、プログラマー自分ご飯を用意しないと、弁当としては完成していない形になってる。

普通の白いご飯を作って追加しても良いし、好みや必要に応じて、炊き込みご飯やまぜご飯を作って追加しても良い。

ゼロから豪華な幕の内弁当を作るのは大変だけど、ご飯だけ用意すれば完成するので楽ができる。

 

プログラムの開発でフレームワークを使うと、プログラマー必要最小限のコードを書くだけでアプリを完成させられるので楽ができる。

 

ライブラリーフレームワークの違い

フレームワーク」と似た用語で「ライブラリー」という用語がある。

イメージとしては、ライブラリーは、ばら売りのおかずだ。

弁当を作るときに使いたいおかず(ライブラリー)を自分で考えて探し出し、選ばないといけない。

フレームワーク最初からおかずが全部用意されているので、自分でわざわざ選ばなくてもOK

 

プログラム動作で見た場合フレームワークライブラリーでは決定的な違いがある。

↑このページの「図1●フレームワークにおける制御の反転」という図解を見てみよう。

制御の反転」(Inversion of Control、IoC)といって、自分の書いたコードが主役から脇役になってる点が違う。

 

(主役と脇役という説明は適切ではないかもしれないけど、イメージとしてはそんなかんじ?)

 

MVCフレームワークとは?

フレームワークはいろんな機能全部入りで、こいつを使えば、ちょっとコードを書くだけで、高機能アプリがすぐに作れる。

ここでは「MVCパターン」という仕組みで作られた「MVCフレームワーク」を使ってみよう。

 

MVCは「Model」「View」「Controller」の略で、MとVとCの3つを自分で用意すれば、アプリが作れちゃう仕組みだ。

MVC歴史は古くて、GUI(Graphical User Interfaceグラフィカルユーザインタフェース)を作る方法定番だ。

→「MVC 仕組み」でGoogle画像検索すると、分かりやすい図解がいろいろ出てくる。

 

(参考)

Wikipedia説明は、文章学術的で難しいけど、正確な説明になってると思う。

↑このページの「MVC概要」という図が、MVCの仕組み=動作の流れを分かりやす説明してる。

 

MVCの仲間たち

MVCパターンと似たような仕組みが、他にもいろいろある。

 

こういうプログラム設計に関するノウハウは、「アーキテクチャー・パターン」という分野に蓄積されている。詳細はGoogle検索してみよう。

 

WAF(Web Application Framework

Webアプリを作るときに使われるMVCフレームワークには、いろいろある。

WAFを使うと、Webアプリが手軽に作れる。

 

有名なものとして、

などが挙げられる。

 

PHPOOP学習しているので、ここではPHPのWAFの1つであるCodeIgniter」を使ってみよう。

 

CodeIgniterコードイグナイター)

CodeIgniterは使い方がシンプルで、覚えるルールが少ないので教材に向いているだろう。

それでは、CodeIgniterを使ってみよう。

 

準備

↑このページの「Downloadから「3.1.9.zip」という圧縮ファイルダウンロードする。(2018年10月現在バージョン3.1.9でした)

 

ダウンロードしたファイル解凍して、「CodeIgniter-3.1.9」というフォルダが出てきたら、「waf」という名前に変えよう。(「waf」はWeb Application Frameworkの略。)

今「waf」フォルダの中には、「index.php」というファイルや、「application」「system」などフォルダがあるね?

この「waf」フォルダを以前用意したXAMPPの中にコピーする。(参照:anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備)

=「C:\xampp\htdocs」(Cドライブの中の「xampp」の中の「htdocs」というフォルダ)の中に「waf」をコピーして下さい。

=「C:\xampp\htdocs\waf」という位置コピーできたらOK

 

動作チェック

これで「Welcome to CodeIgniter!」というWebページが表示されたら、CodeIgniter動作確認OKです。

 

CodeIngiterの設定

$config['base_url'] = 'http://localhost/waf/';

 

Webアプリ作成

それでは「Hello, world!」と表示させるシンプルWebアプリを作ってみよう。

 

MVC「C」作成する。

<?php

defined('BASEPATH') OR exit('No direct script access allowed');

 

class Hello extends CI_Controller {

 public function index()

 {

  $this->load->view('hello_index');

 }

}

ここで注目して欲しいのは、「class Hello extends CI_Controller」という部分です。

フレームワークが用意している「CI_Controller」というクラス継承して、自分で「Hello」というクラスオブジェクト設計図)を作っている、という点です。

ここでOOPの仕組み~継承を使ってるわけですね。

 

MVCの「V」を作成する。

次に、

<?php defined('BASEPATH') OR exit('No direct script access allowed'); ?>

<!DOCTYPE html>

<html>

<head>

 <meta charset="utf-8">

 <title>Test</title>

</head>

<body>

 <p>Hello, world!</p>

</body>

</html>

 

これでWebアプリができました!

今回は簡単なので、MVC「M」は用意しませんでした。(CとVだけで完成)

 

Webアプリ動作確認

Webブラウザーで「http://localhost/waf/index.php/hello」というURLアクセスして下さい。

画面に「Hello, world!」と表示されたら、Webアプリ作成成功です!

 

Hello, world!」の表示だけではショボ過ぎるけど、Webフレームワークを使えばもっといろいろな機能が作れます

詳細は、CodeIgniterマニュアルを参照して下さい。

↑このページで「ユーザガイド(日本語)」を読んでみて下さい。

 

まとめ

 

次回は、OOP理解を深めるための参考書を紹介してみます

 

Webアプリを作るときデータベースがないと不便なので、次の次ぐらいにSQLを学ぼう。

MySQLデータベース)を使えば、掲示板などのWebアプリも作れるようになります

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう ←★今ここ★

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-17

anond:20181016231926

JpopでBPMが高いやつ、低いビートを分周して流行りに合わせた高い計測BPMを出してるだけだから結局遅くて苦痛

パイプラインのあるCPUの話してるのに4クロックで1命令アーキテクチャでなんと4MHz動作です! 高速! とか言われてるような気分になる

2018-10-14

渋谷にあるニュース会社を辞退した話

少し前になるが、転職活動の一環で難易度が高いと言われているニュース会社リクルーターを通して受けてみた。

SNS勉強会を通じて、優秀な人材がいることは事前に分かっていたし、勉強会で実際に話してみるとただ有名なだけのエンジニアとは違い、技術にもビジネスにも明るく仕事が出来る事が直ぐに感じ取れたからだ。相手自分ことなど覚えてはいないと思うが。

時を同じくして同僚も受けていた事が分かり、同僚も辞退をしていたのでどんな感じだったか情報交換を行った。

面接を通してミスマッチが発生しなくて良かったと思っているので、その記録を残してみる。

私のキャリアは、ソフトウェアエンジニアを約10年ほどサーバーサイドのプログラムを多く書いており、十数名規模のマネジメント経験がある。

応募ページを見ると、大量にポジション無尽蔵に羅列してあり、何が何なのか正直よくわからなかったのでポジションサーチというやつに申し込んだ。

自分キャリアから適切なポジションを案内してくれるらしい。

まずここでミスマッチが発生した。先方からフロントエンド関連のエンジニアポジション提案され、戸惑いながらも面接に進んだ。経歴書にはフロントエンド業務で取り組んでいたと書いたためであろう。なお、面接の前にオンライン簡単コーディングテストが行われた。

面接は1日に連続して数人と行うスタイルで、このやり方は初めての体験だった。

最初の人は現場の人だったのであろう。非常に初歩的な事を聞かれた。技術的に深いコミュニケーションが出来ず、少し深ぼった話をすると逆になんですかそれはという反応をされたので、レベルが高くない人なのかと察し適当に流すことにした。

なお、コーディングテストの結果はどうだったのか評価を教えてほしいと伝えると、自分もこの問題はよく分からいからと言われた。一体何のために行っているのかテンションが下がる話である


次はマネージャーとの面接だった。どういうチームがあるのか組織的な事を説明され、相手会社アーキテクチャ説明された。その上でどう改善するかという問題を出された。

こういう面接方法もあるのかと思いつつ、もし前提がこうであればこう改善したほうが良いという提案を何個かしたが、それはこういう理由で出来ないや、今は忙しくて取り組めないという事を返された。隠れた条件を後付けで出されるので、なんかズレてるなと感じ、組織的課題を聞いてみたところはぐらかされた。

面接によくある、最後に何か質問はありますか?と問われたときに、面接の中で聞かれたことを逆質問し、その課題にどう取り組むかの意見を聞いたところ、適当な感じに返された。

この時点で微妙な人たちが連続して続いたので、私の中では辞退をしようと決めていたのだが、是非2次面接に進んでほしいという案内を受けた。

てっきり1次と2次を連続してやったと思っていたが、この日に受けたのはどちらも1次面接らしい。


リクルーターには別のポジションで受けたいこと、可能であればもっと優秀な人か勉強会で登壇した人と面接をしたい事を伝えたが後者は叶わなかったので辞退を申し入れた。辞退の理由は、面接した人と一緒に仕事をする事になると心労が絶えない事を直感的に感じ取ってしまたからだ。


同僚はバックエンドというポジションで直接応募しており、情報交換した感じでは面接官は別の人のようだった。

聞いた話なので詳細を書くことは出来ないが、Kubernetesの本に関わっている有名な人が出てきたようだったが、そのプロダクトの話をしても全然詳しくなく、実際にサービスで使っている自分の方が詳しくてがっかりしたそうだ。今取り組んでいるプロダクトの課題目的、背景を聞いても、よく分からないと返されてしまい、萎えしまったために辞退した模様。その同僚はフリマ会社も受けており、きちんと分かっている人が出てきたのでそちらに行くらしい。


から見るとイケイケな会社に見えても、実際はそんな事は無く、一部の優秀な人がまわしてるんだなと思い悲しくなった。

2018-10-12

静大CS3年のための実験III)、(アカデミックハラスメント対策入門(

(この増田意図的炎上を起こすことを目的として無断転載を行うものです)

無断転載元:https://komeda.hatenadiary.jp/entry/2018/10/09/150830

URLは適宜補完しました)

前置き - 実験IIIについて -

2018年10月9日

CS3年には辛い辛い後期が始まりました。

今までにも辛いものがあったでしょうが、今期のそれは今までをはるかに上回るそうです。

「それ」とは、もう皆さんお分かりでしょう。

「 情 報 科 学 実 験 III」 です。

情報科学科の授業の中で、最も辛く過酷な授業と言われています

実験内容は、静岡大学情報科学科の計算機教育用に開発されたマイクロプロセッサであるSEP-3アーキテクチャ実装、つまりCPU作成を行うことです。

一見、他大学にはあまりない独特の実験面白そうですね。

かに実験内容だけを見れば、コンピュータサイエンス好きな人にとっては、とても楽しそうな授業でしょう。

しかし、実験IIIで辛いのは実験のものではないのです。

それは「 レ ポ ー ト 、 教 員 」です。

実験IIIでは某教員による、かなりシビア指導が行われているらしいです。

深夜2時まで続く発表

地獄の再発表

女生徒を泣かせた上に追い打ちをかける独裁教員

代々名称語り継がれる説教部屋

真実を伝えることさえ許さな独裁教員

反論は死を意味する

教員による圧倒的な理不尽

学生レポートを破る

学生の首根っこを掴んで怒鳴る

学生が一度も習ったことのないことを口頭試問で質問し、答えられないことを立ちっぱなしで1時間以上追求する

私がこれまでに聞いて来た愚痴や某教員暴挙とも言える行いの数々です。

いやぁ、恐ろしいです。

さながらブラック企業のドス黒業務のようですね。耐えられる気がしません。

先輩方の辛そうなツイート収集してみました。ご覧ください。

ズンドコキャベツ太郎

@toradora_haken

somの口頭試問を受けてないくせにsom3は厳しいけど正論しか言ってないだとか正しい事しか言ってない とか言ってる偽善者が嫌いすぎる

あいつは学生を見下してる正真正銘サイコパス野郎だよ

somの口頭試問を受けた上でまだそんなことが言えるならへ〜そういう人がいるんだなで済ませられるけど

https://twitter.com/toradora_haken/status/1010069961295839232

17:00 - 2018年6月22日

れたすのー

@retasnow_tt

僕だったらいいけど、もう1人の泣き出してしまった女子に「何で泣いてるの?」とか聞いてしまうのは本当にデリカシーがないし早くセクハラで訴えられて欲しい

2:10 - 2018年1月30日

https://twitter.com/retasnow_tt/status/958024564864270336

これから実験IIIを受ける皆さんは、耐えられると思いますか?我慢できますか?

先輩方は乗り越えてきました。

恐らく、私も、あなたたちも、乗り越えられるでしょう。

乗り越えた先には何が待っているのでしょうか?私たちは何を得られるのでしょうか?

実験IIIを乗り越えたという大きな達成感は得られるでしょう。

実験により培った実装力、仲間と共に切磋琢磨したことによる協調性なども得られるはずです。

膨大な量のレポートを書いたことで得られる文章力は、社会に出てからも活きてくるでしょう。

このようなものが得られるという点では、実験IIIの授業はとても身になるものと言えます

しかし、です。

教員がやっていること、アカデミックハラスメントに当たりませんか??

深夜2時までの発表や、反論を許さな体制アカハラに刻当するのではと思います

ここで、アカハラ定義確認してみましょう。

アカデミックハラスメント和製英語: academic harassment)とは、大学などの学術機関において、教職員教育研究上の権力濫用し、ほかの構成員に対して不適切で不当な言動を行うことにより、その者に対して修学・教育研究ないし職務遂行上の不利益を与え、あるいはその修学・教育研究ないし職務遂行差し支えるような精神的・身体的損害を与えることを内容とする人格権侵害のことである

アカデミックハラスメント - Wikipedia より

https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%AB%E3%83%87%E3%83%9F%E3%83%83%E3%82%AF%E3%83%8F%E3%83%A9%E3%82%B9%E3%83%A1%E3%83%B3%E3%83%88

先ほど箇条書きした項目の中に、アカハラに当たるだろうものがありませんか?

ありますよね...。

まり、某教員が行なっていることは、教育ではありません。

     「人格権侵害」です。

教育も度が過ぎればなんとやらってやつですね...)

さあ、このような実験IIIの体制を許しておいて良いのでしょうか?

実験IIIのような強いられた環境の中で学習を行うことは悪影響(私の場合

教員理不尽に屈したくない

コンピュータサイエンスを好きでいたい(実験IIIを受けたら嫌いになりそう)

静大を好きでいたい(私は浜松キャンパスが好きです)

実験III受講中アカハラが発生した場合、私は必ずハラスメント報告をしたいと考えています。 (打ち消し線の意図は後ほどほど述べます

このような考えをお持ちの方が、私以外にもいるはずです。

ですが、ハラスメントの報告はどこに?誰に?いつ?すればいいの?と、報告する気持ちはあっても、どう行動して良いのか、誰に相談して良いのかわからない方もいるでしょう。

実験IIIのアカハラ対策、しておきたいですよね。

そこで、今回は静岡大学におけるハラスメント対策方法をご紹介します。

本題 - How to ハラスメント対策 -

ハラスメントとは?

まずは、ハラスメントについて確認しましょう。

先ほどはアカデミックハラスメントについてのみ紹介をしましたが、複雑な社会が展開される昨今、ハラスメントには様々なものがあります

セクシャルハラスメント

アカデミックハラスメント

パワーハラスメント

妊娠出産育児休業などに関するハラスメント

その他のハラスメント

それぞれのハラスメントについての説明は省略しますが。

これらハラスメント共通する点はなんでしょうか?

それは、「嫌がらせ」です。

ハラスメントは、英語では "harassment "と表記し、人を困らせること、嫌がらせなどと訳します。

嫌がらせとは、

他者に対する発言・行動等が本人の意図には関係なく、相手不快にさせたり、尊厳を傷つけたり、不利益を与えたり、脅威を与えること

ハラスメント定義より

https://www.osaka-med.ac.jp/deps/jinji/harassment/definition.htm

です。

ハラスメント嫌がらせ)の定義からも某教員がしてきたことはハラスメントに刻当することがわかります

ハラスメント対策について

このようなハラスメントに対して、どのような対策をすることができるでしょうか。

以下のような対策が考えられます

ハラスメント加害者に対して直談判を行う

内部組織相談する

外部組織相談する

ハラスメント問題は、加害者無意識に行なっている場合もあり、関係者同士で解決を行うのは難しいと言われています

ですから、内外部の組織相談をし、解決を行なってもらうことが一般的です。

静岡大学でも、ハラスメント相談を行う窓口を構えています

静岡大学学生であれば、まずはその窓口に相談を行うのが正解でしょう。

静岡大学ハラスメント相談について

静岡大学におけるハラスメント相談窓口は、大きく分けて二つあります

学内相談窓口と学外相談窓口です。

学内相談窓口は、学内相談員によるハラスメント相談を行います

相談員はプライバシーを固く守り、相談内容の秘密を厳守します。

相談箱を各部局に設置してあり、週一回、相談員が内容の確認をしています

外相談窓口は、静岡大学から委託を受けた事業者が、無料で、相談から相談を行います

相談Web電話にて行うことができ、学内相談窓口同様にプライバシーを厳守します。

特に問題がないのであれば、学内相談窓口に相談を行うのが正解でしょう。

以下では、学内相談窓口について説明を行います

学内相談窓口について

学内相談を行う方法は、ハラスメント相談箱にハラスメント申立書を入れるか、相談員に相談を行うかの二つです。

ハラスメント相談担当する相談員への連絡先は、このページに載っています

相談員の選び方ですが、馴染みのある先生学部先生事務部の方から選ぶと良いでしょう。

また、相談箱の設置場所はこのページに記載されています

相談箱にはハラスメント申立書を入れる必要がありますが、ハラスメント申立書はこのページからダウンロードすることができます

おわりに

ハラスメント問題は、自分解決ができない場合他人相談しないと、解決することはできません。

実験IIIの)ハラスメント問題解決するために、まずは相談員への連絡、相談箱への投稿をしてみましょう。

実験IIIで深い傷を負わないためにも、後輩たちに同じような思いをさせないためにもハラスメント報告はするべきだと考えます楽しい実験IIIを、みんなで作っていきましょう!!)

ハラスメント報告をしたいと考えていたのですが...

私は先ほど、ハラスメント報告をするつもりです、と言いました。

しかし、今は静岡大学ハラスメント報告のシステム、と言うよりも、ハラスメント委員会(というよりかは静岡大学)に懐疑の目を持っています

それは、

「某教員ハラスメント委員会の頭だ。だからハラスメント報告をいくらしても無駄。」という噂を複数確認たからです。

あくまで、噂です。ですから、某教員ハラスメント委員会の頭だということに確証はありません。しかし、報告が意味をなさないというのは強ち間違っていないだろうと考えています

静岡大学では半期の授業が終わるたびに、授業評価アンケート実施します。

そのアンケート内では、任意コメントをすることができ、そのコメント欄を使い実験IIIの体制を変えようと訴えた先輩方が複数いることを確認しました。

ですが、現状はどうでしょう。何も変わっていません。

また、2018/10/10当日、このようなツイート確認しました。

引用させていただきます

すが藁

@sgwrch105

· Oct 10, 2018

Replying to @hanko96

そろそろあいつ訴えられないか

柚子ノ樹

@hanko96

研究室変更の時に色々担当者と話したけど、学務教務カウンセラー辺りは理解したうえで手を出せない状況だったから、学内で何とかするの無理っぽい。糞オブ糞

8:54 PM - Oct 10, 2018

https://twitter.com/hanko96/status/1049991508227584000

やはり、静大内部から実験IIIを変えていくのは無理があるようですね...。

元々は、「静大生にハラスメント報告の仕方を周知し、ハラスメントを受けた人がハラスメント報告をすることで、実験III(その他辛いだけの授業)の体制を変えることができないだろうか」という意図を強く持った文章を書くつもりでした。

しかし、静大当局が動いてくれないのであれば、この文章意味がありません。

ですから静大CS実験IIIの現状が世間に浸透し、静大内部を変えるような強い社会潮流を持ってくれないだろうか...という淡い期待も兼ねてこの文章を書きました。

長くなりましたが、私の根底にある願いは一つです。

幸せな半期を送ること、それだけですから

プログラミング本質カプセル化ブラックボックス

コンピュータマシン語命令文もデータも数値で表す。これは今も昔も同じ。

数値だけでは人間管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ

(わかりづらい数字人間理解やす英単語に置き換えた)

アセンブラも規模が大きくなると人間には管理しずらくなる。

そのため人間言語により近い高水言語が生まれた。

if や for などで制御をわかりやすくした。

複数の処理をひとまとめで扱うサブルーチン関数プロシージャ・ファンクション

いったものができた。

(処理の流れをわかりやすくした、構造化、カプセル化

複数データをひとまとめで扱うレコード型や構造体生まれた。

カプセル化

コードデータをまとめて扱うクラスができた。

カプセル化抽象化

アプリケーションからOS機能を呼ぶシステムコールAPIが生まれ

ブラックボックス化)

複数クラスコードデータをひとまとめにするにモジュールができた。

カプセル化

プログラムを外部から操作するRPC、CORBA、SOAPRMIができた。

リモートから操作ブラックボック化)

WebAPIアーキテクチャーを超えての疎結合が進む

さらなるブラックボックス化)

IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。

ブラックボックス化)

CIツールサーバ数台〜数百台を1人で扱えるようになった

操作の簡略化)

DockerWEB/DB/KVSなどをまとめてコマンド1つで扱えるようになった。

カプセル化抽象化

プログラミングとはわかりづらいマシン語人間にわかやすくするのが本質

カプセル化ブラックボックス化・操作の簡略化は正義

2018-10-08

anond:20181007145044

日本インフラ界隈も漏れなくゴミ情報が古すぎ、アーキテクチャ理解しないで書くからもう、文字のごとくゴミ

英語力のないインフラエンジニアとかクラウド時代にまじでやっていけてない。コンビニ店員とかに転職してほしいわ。

2018-09-25

いつかの社内勉強会ネタに使えるかもしれないので記録。

ContainerPatternで"Ambassador Pattern"(Googleで直訳すると、大使紋章..めっちゃかっこいい)というのがある。

https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador

なにが大使やねんというと、サービスAがサービスBに接続するときサービスA'がサービスAの代わりにしてくれるかららしい。外交官的な。

接続にかかわるもろもろ、回線監視だとかリトライ処理だとか認証だとかそもそも接続する設定値だとかそういったものを代わりにやってくれるサービスを別途にもうけようぜという仕組みだそうだ。

その仕組みがはまる例として

・異なるプログラミング言語だとかフレームワークサービスを織り交ぜている

アプリ開発者が認証の仕組みまで意識して作りたくないよ

という時だそうだ。

ふむふむとうなづきつつ、アンチパターンの方で躓いた。

つのプログラミング言語しか使ってない場合メリットからクライアントに直接通信用のライブラリ入れろよというのは納得...したんだが、

Consider the possible impact of including generalized features in the proxy.

For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent.

一般的機能プロキシに含める影響を考慮してください。例えば、リトライ処理をするとき、全ての処理(注釈: アンバサダーリモートサービスに対する処理)が"冪等"でなければ安全ではないかもしれません。

冪等ってなに?え、リトライ処理でデメリットが生じることがあるの?(ログイン試行回数とか?)

有識者的にはあーっ知ってるよで終わる話(隣の技術者に聞いた感じ)なのかもしれないけどそもそもidempotentの訳を知らなかったので

ググると、"treasure data"の中の人ブログにたどり着いた。

リトライと冪等性のデザインパターン

これだよ!!これが俺が知りたかたことなんだ。ありがてぇありがてぇ。

接続しようとしている外部リモートサービスの話で合って、リトライする側のアンバサダーサービスが考える話ではないし、

接続しようとしているサービスに応じてアーキテクチャ設計が変わっちゃうと本末転倒感あるけど、

少なくとも考慮すべきポイントであることは了解だ。

...はぁ、勉強したー!!

2018-09-12

anond:20180910094331

なんか書いといたほうがいいような気がしたので書いておく。

組み込みといっても範囲が広く、

最初あなた相手にするのはRAM 1kB, ROM 4kB、クロック 20MHzなどというMCUである

なんてところもあれば、中身はARMLinuxですみたいなところもあるし、その中間RTOS使ってます。ということもある。

ただ、歴史的経緯として、マイコン制御などと呼ばれていたような時代から組込みソフトウェア開発がはじまって、

時代をくだるにつれて最終製品機能が高機能化、複雑化するにしたがってソフトウェア開発の規模も比例的に、

あるいは指数関数的に拡大しているわけで、NonOSアセンブラやCで書くという仕事相対的に減っている。

(なんせ、ある程度高価格、高付加価値製品を作らなければ国内メーカーは潰れるしかない)

なので、一番規模が小さいところの仕事はなくなりはしないし、働いている人は食いっぱぐれないとは思うけど、

わざわざ新たに飛び込むのは正直オススメしない。

で、問題は規模の大きい方で、当時マイコン制御をやっていたようなベテランやそれに薫陶を受けた開発者

勉強」をせずにこちらの方にコンバートするとどうなるかという話だ。

コンパイラC++11,C++14であるにもかかわらず、Cもどきコードを書くし、プロセスは巨大だし、

強烈に古臭いアーキテクチャを擬似的にOS上に構築してしまう。

その結果出現するのは、ひたすら肥大化アンタッチャブルになったコードと原因不明バグである

IoTがどうのこうのなんて言っていても、組み込みが専門じゃない人がラズパイセンサー買ってきて

一日半あればできるようなことを、ああだこうだやっているようじゃやっぱり生き残る道はないんじゃないかなー。

2018-09-11

組み込み系で色々思い出したので書く

https://anond.hatelabo.jp/20180909073549

↑で色々思い出したのでうっかり書く。

数年前までメーカ組み込みソフト開発やってた。今はWeb系と呼ばれるところに転職した。

どちらも超大手なので、両親レベルの年齢層でも企業名とかプロダクトの名前を知ってると思う。

元の文をディスってるというよりは、うちはこんな感じだったなーと思い出話と捉えてもらえば。

IoT(笑)なんてもの流行もあり猛烈な人不足。未経験でもホイホイ入れるし、SES拒否しても求人よりどりみどり

知らなかった。どういう機器を扱うメーカ人手不足なんだろう。自分転職活動したとき車載機器メーカ求人がやたら多かった。

最前線でもなければ家でコード書いてる人なんて職場の1割いるかいないかぐらいの緩い競争環境

ソフト開発が好きでそれを超極めてるというよりは、元々優秀で、ソフト開発はいくつかそこそこできることの一つみたいな人が多かったかな…。

旧帝大以上の人がゴロゴロしてたので、その人達まったり仕事してるから一見緩く見えたけど

雑魚国立大学出身自分が120%で戦っても、ゆるふわ系高偏差値大卒の方々に多方面で敵わなかった思い出がある。

自分のいた部署では京大とか九大の人が多かったけど仕事の質速さともに、一生敵う気がしなかった。

その人達にとって仕事なんて神々の遊びみたいなものだと思う。

なので競争に勝つ人は順当に難関大学出身者ばかりだった。

web系はそこに比べると大学難易度仕事出来る度合いの相関がかなり薄いと思う。理由は良くわからないけど、他のメーカ出身の人の話を聞くと同じ感想を持つみたいだ。


会社しか使えない機材で仕事をするので仕事中に必要スキルが伸びる

まあそれはたしかに。ただその企業しか使えないスキルもたくさん伸びる…。

古い体質の企業が多いのであんまりスキルなくても給料は年次で増えてく(ごく一部除いて年収600-650万ぐらいか頭打ちになってくるけど)

1年目で500万ぐらいだったけど5年すぎるとほっといても700万ぐらいになって(ただし残業代含む)

誰でも主任クラスになれてそこまでいくと普通にやってれば800万ぐらいにはなった。子供産むと万単位で月の手当つくし住宅補助もあったし退職金も…。

Web系は給料という面では手当も殆ど無いし、そこを除いた額同士で比較しても普通に低い。同じ額もらおうとすると部長上級にならないともらえない。

古い企業労働組合ちゃん組織されていて、会社と色々バトルしてきた歴史のある企業は、やっぱりベースも高いんだよなと思った。

ごりごり忙しいweb系と違って既婚率高い

組み込みときは深夜残業とか休日出勤しまくってた。既に色々な人が指摘しているけど試行錯誤とか学習含めて会社しかできないんだもの。そりゃそうなる。

web系の今は休日出勤殆ど無いけど、緊急対応電話がかかってくると突発的に対応しなきゃいけないのでそれはそれ。

自分コードが街中で動いてるのを見られるかもしれない

これは嬉しかった。

組み込み系のよくないところ

研究系の最前線を除いて東京23区内で働くのはかなり難しい。全般的オフィス田舎

メーカで言うと川崎横浜に集まりすぎだと思う。


最新の開発ツールに触れてたい人が発狂するような古い環境もちらほら。github知名度アンケートやっても知ってるが2割超えないところが大半だと思う。

自分転職するまでgitとかgithubとか使ったこと無かった人なので…。組み込みときsvnだった。

(ソースコードの最新は共有サーバのこのフォルダなんて運用だったり、

開発部はそこまで酷くなかったけど、評価部隊評価用のソフトバージョン管理してなくて悲惨だった。

不具合一つで人命にかかわる場合もあるので慎重さがないタイプだとレビューボコられる

直接人命を預かる機器に関わったことはないけど、ストレージ系だとバグユーザデータ消えると大トラブルになるのでレビューは厚めだった。

ソフトウェアの品質が高いかというとそうでも無かったと思う…。レビュー担保できるソフトウェアの品質ってわりと早い段階で頭打ちになると思う。

秘伝のタレ化してるけど長く受け継がれて歴史証明しているコードには勝てない。

部門によってはコード1行変えるのに部長承認必要というところもあったみたいだけど(ダムとか電車とかのインフラ)。

ソフト知識以外に弱電の知識がないと一人前の仕事が処理できないケースが多い(仕事でやってるうちに嫌でも身につくと思う)

自分のとこは弱電はまああればより良い(特許提案とかしやすいし、マネージャクラスは当たり前のように回路やメカや量産の知識も求められるのでHW出身が多かった)けど

担当者レベルならそれこそ担当が違うんでってことで回路のことは回路部隊がやってたし、それで回路担当評価が良くなることもSW担当評価が悪くもなることはなかった。

どちらかというとSW担当ならヘネシーパターソンの本から重要な部分を抜き出して読んだ程度の計算機アーキテクチャ知識必要だと思う。

今だとこれ読めば良いんじゃないかな。

コンピュータシステム理論実装

https://www.oreilly.co.jp/books/9784873117126/


グーグル解決法が落ちてないことが多いのでマニュアル(大抵英語)を正確に読む力が要求されることが多い

ググっても出てこない。社内で作っていうrHWモジュール開発者は社内に居ることが多いので、やたらドラクエする力がついた。

汎用的なモジュールになると社外のドキュメントを読む必要があるけど、たいてい英語なのでそこは同意

ただ正確に読んだところで社内外問わず間違えてたり、HWが仕様どおりに動かないことも多かった。

レジスタ設定をするタイミングが超シビアタイミング合わないとHWがロックするとかデータ失うとか。そんなのばっかり。

それがスキルかと言われると、うーん。転職で活かせそうなところとそうでないところはあると思う。

情報に乏しい状態でとにかくやっつけるスキルは身につくかな…。

あとはHWでどうがんばっても再現できないのでとにかくひたすら大量のコードを読むスキルとか。

2018-08-22

セブンイレブンの新レイアウト馬鹿じゃないの?

店内に入って左端に紙パックやカップ入りのチルド飲料、右端にPETと缶飲料

「何か冷たいもの飲みたいな」と店内に入った時、店の端から端を往復しなきゃいけない。

これが従来のレイアウトなら、店内に入って突き当たりがPETと缶飲料、角を曲がればチルド飲料、と距離が近かったのに。

それとも、普通のお客さんは来店前にどのタイプ飲料買うか明確に決めてて行ったり来たりが必要なかったりするの?

それとも、こうすると店内の回遊率が上がってついで買いが増える、みたいなデータでもあったりするの?

気になってるの自分だけかと思ったら、ブコメで同様の意見を見かけたので書いてみた。

セブン、1万店で挑む「売り場大改装」の勝算 | コンビニ | 東洋経済オンライン | 経済ニュースの新基準

パックの飲料は左端、ペットボトルは右端という配置に未だに慣れない。アーキテクチャに沿ってUI設計したソフトウェアみたいだ。2018/08/18 11:22

2018-08-15

anond:20180815075003

うん、「サブカルチャー批評は、戻ってこないと思う。

 

東氏は、最近カメラタッチパネルのことを論じているが、物語ファンタジーではなく、半現実アーキテクチャみたいな世界観の論評は、「サブカルチャー批評現代版なのではないかと思われる。

2018-07-14

人を追加しても立ち上げれない

1.

仕様がわかるドキュメントがほぼユースケース(シナリオ)のみ

下位ドキュメントの内容は上位ドキュメント参照になっててなにも詳細になってない

かい仕様も載っていない

1.

仕様書、設計書がバージョン管理システム管理されていない

ファイル名+日付みたいなそんなちゃちなもんじゃねぇ

最新のドキュメントがどこにあるかがわからない&異なる仕様変更を反映したバージョン複数存在するんだぜ

1.

設計書と実装が一致していない

ドキュメントに変更が反映されてないとかそんなちゃちなもんじゃねぇ

アーキテクチャがまるっと変わるような変更(設計書)をしておきながら

めんどくさいからって実装は古いままなんだぜ

2018-07-13

楽天文句

結構前に楽天株式会社退職していました

noteテストを兼ねて。実は退職してからすでに1年以上が経過しているのですが、ようやく書きたいことがかけるようになったと思われるのでいまさらながら退職エントリを書いてみることにします。

TL;DR

文章にしてみたら、自分がどういう環境で働きたいかが整理できました。自分思考を整理する手段として退職エントリおすすめです。この文章にはそれ以上の価値はありません。

Safe Harbor Statement

ここに書いた内容は僕から見た一方的な内容であり、辞めたひとバイアスがかかっていることをご承知おきください。近しい人が見れば個人特定できてしまうような記述がありますが、個人組織誹謗中傷する意図はありません。

楽天でのおしごと

2011年4月新卒入社。ちょうど6年間、金融関連事業渡り歩きながらWebエンジニアをやってました。お客様に直接向き合うサービスを作る部署なので、開発も運用もやりました。工程でいうと要件定義/設計/実装/テスト/リリースとぜんぶやりました。役割でいうとリードエンジニアっぽい仕事プロジェクトマネージャプロダクトマネージャマネごともやりました。5年目くらいからいわゆる管理職兼任してました。

謝辞

やめる直前はとにかく退職することに全エネルギーを注いでいたうえ、決意を固めてから有給消化という名の出社拒否を行っていたので、お世話になったみなさまにはろくに挨拶もせず退職キメてしまいました。すみませんでした。6年間好きなようにやらせいただきました。自由奔放な僕を多岐にわたり支えていただいた皆様には大変感謝しておりますありがとうございました。

現職について

株式会社ディー・エヌ・エーでお世話になっています。相変わらずWebエンジニアです。素晴らしいタレントに囲まれて楽しくすごしていますエンジニア裁量が大きく、人材に対するリスペクトを感じます自由ライフスタイルマッチします。たのしいです。うぇるかむ。

よかったこ

現職での生活を1年やってみて、良かったなと思うこともまぁ少なくなかったので書きます

面白いことがたくさん起こる

良い意味アグレッシブ会社なので、思いもよらぬ業務提携がおこったり、わけわからんくらい事業が成長したり、(その逆もあったり、)「その発想はなかった」的な新事業が勃発したりととにかく様々なイベントに満ち溢れています。飽きることはないと思います

英語への熱量がすごい

内定式の直後くらいに英語公用語化がうちだされ、「入社日までにTOEICで○○○点とってきてね(とってこないとどうなっても知らんぞ)」的な脅しを人事にかけられました。おかしいな、ドメスティック会社を選んではいったはずだったんだが・・・英語ができない子だった僕は泣きそうになりましたが、さまざまなバックアップ会社提供してくれていたように思います。僕が在籍していた頃は英語一定ラインに達していないと安くはない代償(労基法との兼ね合いどうなってたんだろう?)を支払うことになっていましたが。僕は強要されないと勉強しないタイプなので、結果的英語スキルを身につけることができたのは良かったと思っています

福利厚生が圧倒的にすごい

現職もそれなりに規模の大きい会社ですが、比べてみても福利厚生レベルは圧倒的です。朝昼晩の食事無償提供されてました。会社建物の中にジムコンビニカフェマッサージクリーニングをはじめそのまま生活できそうな設備が整っています研修も充実しています特にエンジニアにとって魅力的なのは海外カンファレンス会社お金で参加できることです。「いいから行け」的にぶっとばされます

事業バラエティがすごい

楽天という会社は中にいても自分たちの会社がどんな事業をかかえているのかわからいくらいにたくさんの事業を持っていますEC金融が有名ですがそれ以外にも大小様々なサービスがあります新規事業への挑戦も常時おこなわれていますライフスタイルも開発スタイル事業ごとにかなり多様性があり、希望すれば社内異動だけでだいたいのやりたいことをかなえることができます

給料が高い

いまでいうとインパクトは薄れましたが、僕が入社した頃はかなり高い水準の初任給を出していたように思いますし、その後もありがたいことに高い評価を頂いていたので(同職種・同年代のなかでは)お給料は高かったほうだと思います

よくなかったこ

主に辞めた理由です。当然にネガティブな内容なので有料にして伏せておきます楽天転職検討している人とか僕の愚痴をよみたい奇特な方向けです。

エンジニアの扱いがよくなかった

これは部署にもよるのでしょうが、僕がいたところではエンジニア立場が悪かったように思います。たぶん僕の被害妄想です。とはいえ、現職と比べると圧倒的に裁量は小さかったですし、ビジネス職のメンバーとの関係も良くなかったと感じます。なんでもかんでもエンジニアが悪いことにされる傾向にあったり、筋の通らない理不尽要求にNOといえるような環境ではなかったとは思います

上司がやっている仕事が楽しそうに見えなかった

僕はたいへん素晴らしい上司にめぐまれていました。そのおかげで好き勝手やってこれたのですが、尊敬する上司仕事は(僕にとっては)つらそうに見えました。自分が将来同じ仕事をやりたいかなと考えると胃がキリキリしてきて絶対イヤだったので。

日本語が使えるとディスアドバンテージ

社内には外国籍メンバーがたくさんいます日本語がまったくできないやつも一定数います。そんなエンジニア日本語サービスを作っています。わからない言語サービスを作るというのは大変なことです。間違った言葉が書かれていても間違っていることに気づけません。利用規約に間違った記述があった日には大変なことです。英語公用語なので、英語が使えても評価されないというのはまぁ受け入れましょう。ただ、かわりに日本語が使えることが評価されるかというとそうではありません。ただ単に日本語がわからないやつの代わりに仕事が増えるだけです。ビジネス人間日本人ばかりで英語使わないことが多く、調整系のタスク忙殺されるのが嫌になったので。

会社がでかいのでイケてない制約がたくさんあった

システムインフラは構築はどこの部署にお願いして、root必要DB操作はまた別などこの部署にお願いして、それが何営業日必要で、とかシステム開発時の制約とか部署またぐ作業リードタイムがなんぼとかいちいちめんどくさい上に新しいことをやろうとすると面倒なことがたくさんあったので。

会社がでかいのでアレなやつが一定数いた

僕が最後に携わっていたサービスが世の中に出たのでちょっとみてみたのですが、平成も終わろうとしているのにjQueryバリバリ2000年台初頭構成Webアプリが完成していました。僕が置いてきたReact+マイクロサービスアーキテクチャは無事闇に葬られていました。僕のチームがコミットしていたリリース日よりも10月遅れリリースでした。どこからともなくさっそうと現れた「そんな複雑なシステム運用できない」などとのたまう向上心のなさそうな、他人アイデアケチをつけるのがうまいベテラン(?)エンジニアがすべてをひっくり返してしまったようです。(そいついかにアレかを13くらいの言葉説明できるのですが長くなるのでやめておきます)その人物提示した見積もりは我々がそれまでに費やした工数3分の1程度だったので、そのとおりに行っていれば去年の夏には終わっていたはずなのですが。そのエンジニアがアレなのは言うまでもないとして、そいつのアレさを見抜けない上長や、IT企業にいながらエンジニアがなにを大事にしているか理解できずに無茶苦茶判断をするビジネス人間に囲まれ仕事をするのが辛くなったので。おかげさまで僕の最後仕事はその案件作成したすべてのソースコードの破棄でした。メンバーには申し訳ないことをしました。

評価理解不能だった

退職を決意した最も大きな理由ひとつです。前職最後の人事考課の結果が極めて不満だったので。「どう考えてもこの人達より僕の評価が低いことはないだろう」と思っていた同じ職位の人間よりも評価が低かったうえに、それに対する納得の行く説明も得られなかったので。その当時僕の評価担当していた上司は非常に管掌が広かったので、いち部下の評価まで細かいことを気にしている場合ではなかったのかもしれませんが。その瞬間この会社に対する信頼は地に落ちました。

半年待ちたくなかった

その後、非公式な場で「評価がまずかったのは申し訳なかった。半年耐えてほしい(※楽天では評価が年2回)」というようなことを何人かの上司から言われましたが、それはつまり半年待った結果として正当な評価を受けられる」という僕がただ半年間不当な評価を受け入れるだけで、特段メリットがない提案でした。そこに対してどのような補填がなされるかといった説明はなく、耐えた後に得られるものも大したことはなさそうで、しかそれから半年間の仕事も特段熱意を注げるようなものではなかったので。

朝会という制度がどうしても気に食わなかった

毎週1回(事業によってはそれ以上の頻度で)朝会があります。朝8時からです。そんな時間に起きたくありません。裁量労働だろうがなんだろうが関係ありません。出社しないとどういう扱いを受けるかはここには明言しないでおきます労基法以下略)。それはヨコにおいておいても朝8時です。内容がつまらないとかではないですが、いちポンコツ社員としては「8時に始まるから7時58分までに出社しなさい」といわれて間に合うように起きることと天秤にかけるほどの重要性が最後まで見いだせなかったので。(というわけで、僕はこの制度が残っている間は絶対楽天に戻りません。)

英語化無理しすぎだろとしか思えなかった

応募者に要求している英語ハードルが高い(割に待遇が良くない)ので、優秀な日本人採用することが極めて難しくなっていたように思います。そのかわり英語はできるけどそれ以外は普通な人物はたくさん応募してきていた印象です。所詮国内に根ざした企業なので、実務で必要になる英語レベルはそんなに高くないです。なので英語ができない人のカバーをするのは難しくありませんが、優秀なエンジニアがいないのを何とかするのは極めて困難でした。会社方針のせいで本当に採用したい人が採用できず、自分目標にしたいと思える人物切磋琢磨したいと思える人物が同じ組織に現れず、いろんな意味で先がなさそうだったので。

管理職は向いてなかった

上司からお話を頂いたときは嬉しかったですし、それなりの使命感をもってやっていたつもりでしたが、いま思い返すと管理職の道を選んだのは失策でした。できることは増えましたが当然にやらなくてはいけないことも増えました。僕がやりたいことではありませんでした。とはいえ当時はやりたくないといいだせる状況でもなかった(と思っていました)し、自分キャリアアップにつながるなら...と打算的なことを考えてもいましたが、僕の考えは甘かったということが後にわかったので。

というようなことを考えていたら働く意欲がなくなったため

以上のような経緯により、それまで持っていたモチベーション迷子になったので。面白いこともまぁまぁあり、ストレスもある環境でした。「それでも会社必要としてくれるなら...」と思っていましたが、「お前の代わりなんかいくらでもいるよ」という空気を感じた途端に熱が冷めました。

まとめ

正直、辞めた当時は自分判断が正しいのかどうかに結構なやみました。勤めていた時はそんなに悪くないと思っていたのですが、現職を経験して思うのはやっぱり楽天エンジニアエンジニアリングするのには向いてないということです。社内政治が得意な方にはおすすめです。

2018-07-03

anond:20180703134436

イジメコストが安すぎてしかも反撃にあいにくい。

いじめっ子にやさしいアーキテクチャだよね。

イジメた奴に反撃する方法があれば良いような気もするが、

結果としてただ単にうんこを投げつけ合うためのプラットフォームになってしまう気もする。

2018-05-16

anond:20180516161928

そもそも人間って脳のアーキテクチャちゃん理解できてんの

できてないから手頃な努力目標としてとりあえず再現してみよかってやってるんだと思ってるんだけど

2018-04-20

anond:20180420160242

都市アーキテクチャ云々言ってたのは俺だけど

高崎とか大津とかって何の話やら…

話に困ったからって相手属性エスパーしようとするのは悪い癖だよ

anond:20180420151833

都市というのはよそから人が来ることが多いのだから、「分かっていなければ迷う」というのはアーキテクチャとして質が低いんだよ

わかるかなあ?

anond:20180420151019

慣れなくても、格子状だと迷いようが無いでしょう

まれ育って慣れていなければ迷うようなアーキテクチャが良くないと思う

2018-04-02

anond:20180402131358

「一通り」の定義も、何をやりたいかに依るので、なんとも。

と、律儀にマジレスしてみる。

プログラミング言語範囲で「ある程度他に考え方の転用が効く」という意味なら、

最低でも、OS操作できるスクリプト言語bash系やWSH+VBScript/JScript, PowerShell等)と、

汎用スクリプト言語RubyPython等)もやっておいた方が良いかと。

お仕事で、という話なら言語よりはライブラリの使い方やアーキテクチャへの理解プロジェクトルールを守れるようになる、といった事の方が重要になってくるし、

得意分野を作ってもらった方が仕事を振りやすくなるので、「言語に詳しい(だけの)僕」的な器用貧乏にならないようにね。

ちなみに自分今日はお休み

2018-03-26

エンジニアである俺の最近マインドについて

エンジニア一兵卒40台なんだけど

フロントエンドは流れ早すぎgulpだかなんとかzly とか多くて辛いし、js 嫌いだし、typescript ?、結局同じでしょ。むりー

・おれの主戦場web アプリだぜ。でも、rails案件としてはやったことないし、いまから rails やりなくない、php もいまから php7 とか laravel とか追いつけないわ。むりー

課金とか決済まわりの面倒くさいの、むり。レポートだすのめんどい。何かあったときメンタルつらいし、監査対応? むりー

機械学習数学才能ないし、金かかるし、python3.0 ? インデントブロックつくるのあわない。むりー

goツール書く、なに書いていいのかわからん。むりー

アプリ設計指針多すぎ。クリーンアーキテクチャとか MVVM? MVP?、むりー

kotlinelixir ? むりー

俺はエンジニアなんだけど、なんか詰んでる。メンタルが。むりー

どうしたらいい?

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