「SQL」を含む日記 RSS

はてなキーワード: SQLとは

2017-07-18

SQL

SELECT

col1,

col2,

FROM

table

これでFROMの周辺にエラーがありますとか言われる仕様はなんの意味があるのだろう

SELECT対象やす度に面倒くさくて仕方ない

,を先頭に持ってくる方法もあるんだろうけどまったく美しくない

2017-07-10

https://anond.hatelabo.jp/20170710201509

やっぱりそういうこと?

このままSIerで耐えててもWeb系で役立つスキルなんて何一つ身につかないということはわかってる。

でも、ここで今すぐブラックWeb系でもいいから飛び込んでスキルを磨くのと、しばらくSIerで耐えながら余暇スキルを磨いて悪くないところに転職するのと、どちらがいいかがわからねえ。

今のスキルJavaがそこそこ(ユーザーSIerの同期の中では)できるだけ。SQL簡単なサブクエリぐらいしか書けない。データベース設計もあまり経験がない。インフラ知識ゼロ情報処理応用情報技術者ネットワークスペシャリストをマグレで取った程度。

2017-07-04

きょう恥ずかしかったこと

SQL の集計関数の COUNT(*) を、前職の内輪ネタで「カウントアナル」って呼んでたんだけど

新しい環境下でさっきうっかり使ってしまった。

流行らないことを祈る。

2017-07-03

https://anond.hatelabo.jp/20170703153630

出来ないわな。時間かかりすぎる

でも、出来るレベルもあるし、ビッグデータ規定いからどうでも良いんじゃね?

SQLEXCELでもR叩いても結果が同じなら問題ないでしょ。

2017-06-30

主要なしすてむがしんだ

上司mdbをaccdbに変えちゃってエラーが凄い。

え?これ俺直すんです?VBA?SQL?

HAHA。私If Range("A" & i) <> "" Thenとかでキャッキャッしているレベルですよ?

という状態夜逃げしよう。

2017-06-26

ORM死すべし

俗にいうDBおじさんなんだけど、一般的なORMのそのどれもが普通にSQL書くより煩雑になってそれでいて流用も効きづらくてパフォーマンスも悪いってなんなの。

ORMがあるって理由だけでソースの中がクソパフォーマンスの悪いORMを利用したコードで溢れることなんて日常茶飯事だし。

正直言って、なんでおまいらはそんなにコードを汚してまでORMにこだわってるんだ?

2017-06-24

競技プログラミングをやってみた

これまで業務システムの開発をやってきて、自分一人でも

要件定義から開発、運用まで全部こなせていたか

それなりにプログラミングはできていると思っていたけど、

競技プログラミング全然違う分野なんだな。

業務システムでは言語仕様ライブラリの使い方を覚えて、

データの見せ方をどうするかを考えるのが重要だと思っていて、

アルゴリズムデータ構造よりも、DBテーブル設計

すっきりしていると、SQLだけできれいに取ってこれるから

これまで気にした事がなかった。

競技プログラミングは、学校で習ったプログラミングに似ている。

(まだ初級問題しかやってないからわからないけど)

現場で利用する言語ライブラリも一通り習得してしまったし、

システム構造もある程度決まってきて余裕が出てきたから、

しばらく競技プログラミングをやってみようと思う。

しかし、競技プログラミングの難しい問題を解くと、

転職オファーが来るらしいけど、こういうアルゴリズム

必要とする業界ってどういうとこなんだろう?

普通の人事、経理生産管理物流なんかのシステムしか知らないか

想像がつかないや。

プログラマー技術力とは

やっと理解したけど、出来るだけコードを書かないことなんだな

GitHubでいい感じのライブラリを見つけて、sqlマイグレーション

サーバーレスコンフィグ設定もせず ほぼせず

スケーラビティawsEC2クラウドフロント、S3使っていいかんじ

AIAPIでなんとか

シコシココード書くのは古くなった感じある

2017-06-07

anond:20170513175715

残酷だが「職業訓練プログラミング」という人たちはこの業界はあきらめた方があなたのためにとって良い。

そのような人の上司になったことが何度もあるが成功した人を見たことがない。

はいものの、私も35歳から異業種転職にてアプリ屋になったが、転職直前の段階でC/C++/Pascal(Delphi)/html/js/SQL が書けた。

10代前半から8bitCPU(特に名を伏せる)のマシン語(ハンドアセンブル、つまり16進数直書き)でプログラムした経験がある。(もちろんBASICもある)

8bit時代ならメモリー増設設計実装(ハードウエア)ができた。

一応そのような状況ではあってもプロに知り合いもなく心配だったので、

(当時)第二種情報処理技術者試験に3週間の勉強(1.0/日程度)で

一発合格しなければ転職しないというような目標もたててクリアした。

技術的には 0 スタートではかったからこそ転職にも成功できたと思っている。

おっさん技術知識経験ほぼ 0 スタートはきついでしょ。

おっさんなんだからこそ無駄時間を使わないでほしい。

自分も一流でもなんでもないくせに上から目線で自慢話みたいのしてごめんなさい。

あなたに向いた仕事はきっと他にある。がんばれおっさん

2017-06-01

NGT不正投票だと騒いでる人へ。

まあDBをいじったことのあるプログラマならば、

重複投票は「できない」事を即座に理解できるだろうが、

そーでない人へ説明しますね。

データベースDB)には「テーブル」というもの

複数入っており、この中にデータが収められます

データには1つ以上のフィールド(項目)があり、

このフィールドには「ユニークキー」というのが設定できます

ユニークというと日本では「おもしろい」とかい意味で捉えられますが、

本来は「一意性がある」、簡単に言うと「他にない唯一のもの」という意味です。

これを設定しておくと、「同じ値を2つ以上登録できなく」なります

プログラムいくら登録データを送っても、DB側が弾きます

投票データは「投票コード」と「立候補メンバーID」が入るでしょう。

公式サイトユーザーとして投票するなら、

自分ID」と「立候補メンバーID」が入ると思います

前者は投票コードがすでにユニークであり、

後者は双方の組み合わせがユニークとなるでしょう。

こんな簡単な設定をシステム開発会社がしてないとはとても思えず、

重複投票は弾かれるはずです。

一万歩譲ってこの設定をしてなかったとしても、

集計時にSQLひとつで重複を炙り出せます

よって重複投票はまずありえないです。

ならなぜサイト上では受け付けられたように見えたかというと、

それはサイト側の問題です。DB登録リクエストを送った際、

重複してればエラーが返ってくると思いますが、

そのエラーを取得せずに無視して単純に

投票ありがとうございました」の表示をするような

手抜きプログラミングをしてしまったと思われます

要するに投票データを受け付けるDBサーバ

NGT公式サイトは別のシステムであり、

NGTサイト側のみの不具合です。

よって、重複投票はありえません。

おぎゆかおめでとう!!!

これから最悪1票も入らなかったとしても、選抜は確定だ!

何度もオーディションに落ちながらも諦めなかった苦労人に

光が当たるととても嬉しい。よかったね!

2017-05-31

http://anond.hatelabo.jp/20170531005751

SQLコメントを書く

このSQLは何をするために何をしているのか、いつどのような目的で使うことを想定して書いたのか

を書く。主に自分のために。

でも、SQLって運用段階に入っていくと、少しづ更新されていくじゃん。そうするとコメントと合わなくなっていくんだよね…それが辛い。

http://anond.hatelabo.jp/20170530233852

SQL意識して書かないと死ぬほど読みにくくなるのが気に入らない。

前の職場には何もかも全部大文字表記し、ろくに改行も入れないバカが居て死ぬほどつらかった。あろうことか、読みづらいクエリを書ける自分プライドを持ってるっぽかった。ああいう奴とは二度と仕事をしたくないよ。

SELECT COL0,COL1,COL2 FROM TABLE0 WHERE COL0=1000 AND COL2 IN (100,102)

これを少しでも読みやすくするために予約語大文字カラム名テーブル名を小文字表記している (カラム名テーブル名が大文字で決め打ちされているなら、予約語を小文字統一している)。

SELECT col0,col1,col2
FROM table0
WHERE col0=1000
  AND col2 IN (100,102)

しかしこの方法も万全ではなくて、例えば複数テーブルが関連するクエリ

SELECT t0.col0, t0.col1, t0.col2, t1.col0
FROM table0 t0
  LEFT OUTER JOIN table1 t1 ON t0.col3=t1.col3
WHERE t0.col0=1000
  AND t0.col2 IN (100,102)

みたくなってしまう (テーブル名のtable0、仮名t0、カラム名col0が全部小文字になっているため、なかなか読みづらい)。

皆さん、どうやって工夫されてますか?

2017-05-30

SQLが好きになれない

たまにSQLを書くのだが、やはりSQLが好きになれない。

構文によって書き方が違うのがわかりにくい。

SELECTはまだいい。問題はINSERTとUPDATEである

INSERTはVALUESで書くくせに、UPDATEになるとSETで=でつなげているのモヤモヤする。

さらに()が必要な構文だったり必要ではないものであったり統一感がないのが混乱する。

INTOで文章らしさを出しているのかしらないが、どちらにしろ文章にならないので中途半端なのでいらないのではないだろうか。

長ったらしいSQLを書かされるのがとてもクレイジー

ちょっとした検索したい場合はいいかもしれないが、プログラムの一部としての長ったらしいSQLは可読性も悪ければ保守性も悪いで誰も得しない。

さら解決される順番が未だによくわからない。特にGROUP BYを使う場合にどういったタイミングでされるのか非常にわかりにくい。

サブクエリ無駄に重ねたり、ON DUPLICATED KEY UPDATEをわざわざ書いたりとなぜ1文で完結させようとするのだろうか。

どっちみちトランザクション複数文になるのならば、最初から複数文となることを前提した仕様としてもいいのではないか

そもそもコードから呼ぶ場合フレームワーク周りでなんとかしろという話ではありますが)

他にもストアドプロシージャやSQL高速化問題もあるとは思うが、自分自身が未熟者でそこまで語れないので書けない。

プログラミング言語については様々な文句が噴出するにもかかわらずSQLについて文句が出ないのはどういう了見なのだろうか。

反対にNoSQLRDBMSのようなことを始める本末転倒な人たちも見かけるがそれぞれ適材適所な使い方をするべき。

体系的に学んでいれば今よりもっとすっきりと理解できるものかもしれないが、嫌悪感を抱いてしまった以上は学ぶことなくずっと憎み続けていくことになるのだろう。

そういうわけでやはり僕はSQLが好きになれない。

http://anond.hatelabo.jp/20170529142727

みなさん、返事ありがとうございます。初めてで書き方が悪く、答えようがなかったですね。皆さんの質問に答える形で補足させて頂きます

名古屋から1時間ちょっと人口8万人の都市。全国の普通チェーン店がある、普通田舎テレビは7CH映ります自然うまいバランスで住みやす都市だと思う。

年齢は45歳くらいまでがいい。もちろん若くてもいいです。

スキルレベル

【具体的な業務

サーバーメンテナンス作業

・各種開発作業

主に、以下のような開発作業があります

1)サーバー側で稼動してる、パワコンデータ受信プログラムPHP / sh

2)端末側で稼動している、データ取得送信プログラムC++ / PHP / ash

3)Web管理画面HTML、およびCGIプログラムHTML / CSS / PHP

データメンテナンス作業

データベースMySQL採用しております

MySQLクライアントアプリより既存データ修正や削除、データ入れ替え等を行います

大量件数場合は、SQLクエリ作成し一括で操作を行います

などです。まあ、実際は今のサービスは開発よりも、運用保守重視。主にサーバー上のプログラムデータの整理が主です。

上記よりも、使い始めた人からちょくちょく問い合わせが来るのでその対応がメインになると思います

仰るとおり、美しいプログラムでほぼソフトウエア的な保守必要ないです。

仕様変更機能追加もその方にやってもらうので。

上記まで(ほぼ問い合わせ)が一日1時間くらい。

残りの時間を使って、新しいサービスを僕と二人で考えたい。

から求めるスキル新サービスを何とか形にしようとする意識情熱グーグル先生に聞いて自分問題解決しようという気があればいいです。

もちろん、あるに越したことはないですよ。その分しっかりお支払いします。

フィロソフィーすごく、言葉に突き刺さります

具体的には 下請け仕事はしない。自分たち面白いと思うことしかやらない。(開発しない)

エンジニアの人にはアイデアは僕が出すから形にして欲しい。それか一緒にアイデア出しあって、面白いサービスリリースしよう。マネタイズ経営者(僕)が考えるから

上記スキルがあって

年収は400万~

勤務地名古屋から電車で1本 1時間半。

いざとなったら出社は週に2-3回でもいい。

都会から弊社の近くに引っ越してくれるなら、アパートくらい用意します。

釣りスキーロードバイクアウトドアが好きなら、申し分ない環境だと思います

はてなはじめてで、ここでいきなり全部書くのはちょっとと思って、ふわっとした最初で、様子見でごねんなさい。

さて、これくらい書けばちょっとはおっ!って思ってくれるのであろうか?

前回意見頂いた皆様含めて、もっと意見下さい。

意見くれた人たち!ありがとう!これにも意見下さい。

希望者は僕にコンタクトして下さい。

あー、実際のサービスアドレス書けば一発なんだけどな。このもどかしさ。

2017-05-27

SQLサキエルっていう人がいて困惑している

スクルとかサキエルとかリヌックスとか通ぶってんじゃねぇよ

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドVBAから、Rやら自社製品の解析用環境の割と珍しいタイプスクリプト言語など(特定されそうだからぼかすけど。)

とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手作ってみたりして提案していた。

物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。

この辺で気付いたことだが、製造業ITリテラシーは驚くほど低い。製造業一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。

なんせまともにプログラムを書いたことが無い新人半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。

ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。

(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)

2年目に気付いたのは、弊社エンジニアITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。

製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。

無骨だが使いやすイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。

から逆に言えば下々の人間コピペでなんとか恰好を整えられるのだった。

彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。

私はそれに感動した。なんせWebスクレイピングみたいな方法他人が社内プラットフォーム社内WIKIに上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2017-05-08

勘違いしてる同僚プログラマ

29の時にプログラムを始めて今年で3年目。

最初派遣会社にいたけど4月から転職

今の同僚は専門卒業してから10年以上やってる人。

彼の方がひとつ上だけどまあまあ同い年みたいなかんじ。

最初10年以上やってるんだからできる人なんだろうと思って接してたけど

この1か月一緒に仕事した結果すべてが適当レベルが低いというのがわかった。

でも彼はそうだと思ってないようで何かと上から教えたがる。

入ったばっかだし試用期間だから素直に聞いてるふりをしてる。

それでも適当なことばかり言ってくるからいい加減限界が近づいてる。

リレーション使うとSQLが重くなるからなるべく使わないようになど)

つらいのがレビューとき

彼の適当仕事に対して本当は言いたいんだけど

立場は後輩なわけで実際指摘した方がいいのはわかるけど

それでも先輩の仕事ケチつけるわけにもいかないじゃないですか

からないふりして質問して遠回しに指摘しても全く気付かないし

これはおれのやり方が悪いのは重々承知だがそれでも

彼よりおれの方がまともに仕事してるっていうのは1か月仕事したらわかると思うんだよ。

明日からまた彼と仕事するって思うと憂鬱しょうがない。

さすがに1年やったら彼も理解するからそれまで我慢するしかない。

2017-05-05

http://anond.hatelabo.jp/20170503151008

マジレスします。

MicrosoftExcel親和性の高い、Power BIというビッグデータ分析ツール無料で出しています

https://powerbi.microsoft.com/ja-jp/

あなたは、これかこれに類する分析ツールを使って、自社データ分析ができるようお膳立てをし、できるならいくつかの分析サンプルとともに部長さんに提案すればよかったと思います

この手のツールは、データ分析SQL専門家じゃなくても使えるようになってるので、部長さんも十分使いこなせる可能性がある。

知らないことはできないわけで、できるようにお膳立てするほうが、あなたにとっても部長さんにとっても会社にとっても利益になるのではないかと思います

からでも遅くありませんよ。

2017-05-04

http://anond.hatelabo.jp/20170504171337

あんまり詳しくない事務系の人間が言うんだが、

増田用途だとAccess使っても結局フロントエンドExcel使わんといかんような気がするので、おすすめしない。

といってExcelだと無用に重くなるというのはよくわかる。

ソートに関してはマクロとかで改良できると思うが、重くなる問題はどうしようもなかろう。

ハードウェアアップグレード対応するという姑息手段もあるが、Excelファイル肥大化していくだろうから問題を先送りにするだけという気もする。

きちんとしたデータベースSQL)の知識があれば解決できるのだと思うが、かなり敷居が高い

似たようなことでずい分昔に悩んだことがあるので、思ったことだけ書いた。参考にはならんな。

しかあのときは、中途半端マクロ書いてごまかして、そのあとで会社辞めたんだったわ。

2017-05-03

DBSQL理解できない文系上司

ECサイト運営を任されて4年。これまで蓄積された販売データは50万件以上に上る。

もと営業マン上司部長)がこの販売データに目をつけ、分析したいと言い出した。

どういったデータが欲しいのか要件定義をしてもらえればいくらでもデータ提供するのだが、この上司は「自分分析をしたい」という欲求が非常に強い。

そして具体的な分析イメージが持てていないので、要件定義が全く出来ない。

「色々といじってみないとわからない」の一点張りだ。

それじゃ、って事でECサイト管理者権限を与え、管理ソフト上での閲覧もcsv吐き出しの方法も教えたのに、今度はそれが使いこなせない。

毎日ギャーギャー騒いだあげく、ついには「全部のデータExcelで見れるようにしろ!」と言い出した。

「ビックデータ解析に一番有効ツールExcelです。」だそうだ。

部長の後ろの本棚最近そういう本が並んでいるのは知ってた。知ってたけど関わりたくなかったので無視していた。

それがついに正式業務命令として振ってきてしまった。もう避けることは出来ない。

祝日出勤のイライラMAXだったので、昼休み明けに1.5GBのcsvデータ作って部長PCに放り込んであげた。

部長は大層喜んだ。「やっと分析に着手出来るな!」って他部署に聞こえるくらい大きな声で宣言してた。

で、さっきからファイルを開こうとする毎に画面真っ白になる”っていうのを延々繰り返して「なんだよこれー!!」ってキレててウケる

2017-04-26

SQLってさ、新しい書き方覚えてなんか「おっ!使い方わかったわ!」とか思って

練習問題みたいなのやるじゃん?

わかんないじゃん?

不思議だよなあ

2017-04-24

業務命令でなく業務外に業務させたい

新人SQL業務外で勉強させたいと思っている。

もし、勉強しなかったらちょっと単価の高い別のメンバーにやってもらう方が安上がりなので、業務内で勉強させるつもりは無い。

SQLを使った業務をして貰う予定だから勉強してこい

NGで、

SQLできるメンバーにこの業務やってもらおうと思っているよ。

大丈夫だろうけど、

・もしSQL勉強してきたら、次この業務やってもらうよ。勉強しなくても別のメンバーに頼むから大丈夫だよ。

・もしSQL勉強してきたら、次この業務やってもらうよ。勉強しなくても別のメンバーに頼むから大丈夫だよ。ただ、君の評価に与える影響は大きいよ。

真実だとしてもダメかな~?

どこまでだったら、良いかな?

あとはSQLじゃなくて、英語だったらとか、汎用性のない業務パッケージだったらどうなんだろ。

2017-04-22

http://anond.hatelabo.jp/20170421230333

今、仕事をしてるシステムは、DBテーブルカラム漢字になっていてすごくわかりやすい。

SQLとか、

SELECT 
  商品名, 
  商品略称, 
  仕入値, 
  売価 
FROM 
  商品マスタ 
WHERE 
  仕入日 >= '2017-04-01' 

みたいな感じ。

DBからとってきた値をいれる変数も同じように日本語にしたらめちゃくちゃよくなりそうだけど、残念ながら既存ソースがそうなってないから俺もソースのほうはローマ字で書いてる。

2017-03-15

毎朝ぎりぎり出社の運用エンジニアです

今日会社障害対応

最近やっているプロジェクトはつまらない。

今やっている仕事の50%は運用プロジェクト関係

運用なので実装や開発ということもなく、何かシステム修正があればテスト、というような感じ。

障害も頻発するわけではないがそれでもつらい。

先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、

やっぱり運用プロジェクトというせいかモチベーションが上がらない。

最近は毎朝起きるのも遅い。

乗る電車もいつもぎりぎり間に合う電車

以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり

本を読んだり、ランニングをしたり自由に過ごしていた。

会社にはみんなよりも1時間早く来ていた。

きっとその頃は仕事が楽しかったのだろう。

会社に入ったばかりでやることはどれも新鮮。

少し難しい仕事も任されるようになってきてモチベーションもあったと思う。

仕事楽しいだけでなく充実感があった。

それが今では不思議と朝起きたくないのだ。

起きるのがつらいというか億劫

別に疲れが溜まっているわけではない。

目覚めは悪いどころかいつも目はぱっちりしている。

でも起きれない。ぎりぎりまで布団の中。

そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。

まり憂鬱なのだ会社に行くのが。

この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。

今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。

会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。

そういって同僚はフリーランス転職した。

今では職場でも私生活でもいきいきしている。うらやましい限りだ。

自分フリーランスにはなろうとは思わないけども、少なくとも今のプロジェクト半年が限度かなーとは思ってる。

同じ環境にずっと居ても成長できるか不安だし。

それに自分市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。

そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。

運用プロジェクトの残念なところは、仕事の大半が顧客対応コミュニケーションコストでつぶれること。

特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。

障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..

なんてことをつらつら書かなければいけなかったり。

なにより障害が発生したらものによっては休日にも出勤しなければならないこと。

まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。

体力には自身があるけども精神的にはわりときます。人によるのかな?

つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。

運用プロジェクトでは顧客対応必須だ。なので顧客との話し合いは上手くなる。

あと、運用エンジニアには広範な知識が求められる。

例えばフレームワーク脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。

ハードウェアミドルウェア障害が起きればそれに対する知識を駆使して対応を行う必要があるし、

ドメインが変わった、IPアドレスが変わった、となればシステム運用保守作業で影響がないか調査する必要がある。

なのでそのような対応を考える機会があるので勉強にはなる。

他にも必要知識として、プログラミング言語SQLはそこそこかけて、DBクライアントLinux操作、その他ミドルウェア知識必要になる。

なので現時点では自分スキルはそこそこ伸びてはいるのかなーとは感じている。

そんなこんなで運用プロジェクトは色々大変だよってことです。

理想運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。

めんどくさいことが多いけどもつまらなすぎて潰れないようにとりあえずがんばります

明日仕事ですね。みなさん一緒にがんばりましょう。

2017-02-19

SIerの書くSQL

http://uxlayman.hatenablog.com/entry/2017/02/12/low

SQLしかできないマン」の章。これなー。ISAMデータベースなごりじゃないかな。DBの変更を高度に隠蔽化するとかなんとか。

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