SRAU Factory さんはインスタンス qiitadon.com のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。 もしお持ちでないなら こちら からサインアップできます。

SRAU Factory @sraufactory@qiitadon.com

固定されたトゥート

Github Pagesを使って、公式ポートフォリオを公開しました!!

sraufactory.github.io/

基本、各種アカウントのリンクと、Qiita/Githubの記事の一覧とリンクが載っています。

コンテンツはこれからも拡充予定ですので、ぜひご覧ください。

macOSをMojaveにバージョンアップしたら、やはり問題が。。。
ということで記事にしました!

macOS Mojaveにバージョンアップ後、VirtualBox/Vagrantが動かない場合の解消方法 by SRAUFactory qiita.com/SRAUFactory/items/ad

SRAU Factory さんがブースト

・できる
・できない
・品質を上げすぎて時間内に仕上がらない
・時間内に終わるけど品質が足らない
・機能が増えてくると管理しきれなくなる

できるけどやらない方がいい仕事ってあるよね

SRAU Factory さんがブースト

人は忙殺されると注意力が散漫になるけんねー。

アジャイル開発での見積もりの参考になりそうですね。

スプリントのキャパシティを明らかにする方法 ryuzee.com/contents/blog/7135 @ryuzeeさんから

これを守れるユーザー企業ならば、
さぞかしWebシステムの開発は平和に終わると思います。
システム開発者としても意識して提案したいですね。

悪徳Web制作会社にぼったくられないために!簡単にできるチェック方法お伝えします - 経営ハッカー | 「経営 × テクノロジー」の最先端を切り拓くメディア keiei.freee.co.jp/how_not_to_g

switch文もif~elseif~elseもそうですが、
分岐が多い場合は連想配列やマップ使って、
ポリモーフィズムを意識すれば、
分岐はほぼ要らないはず。

むしろ分岐を増やさないと生けない場合は、
分岐を増やそうとしているコード自体の見直しが必要なはずです。。。

SRAU Factory さんがブースト

Pythonには switch 文ないですが、簡単なものなら辞書(連想配列)を使えばswitch的なことができます

def switch(case)
switch_db = {
"a": "python",
"b": "ruby",
"c": "perl"
}
return switch_db[case]

case = "a"
switch(a)
# "python" が返る

スタートアップとの仕事では、
エンジニアサイドとビジネスサイドが揉めるケースはよくありますが。。。
(私も経験あります。。。)

これは良い解決事例かもしれません!!

エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ | PLAID engineer blog tech.plaid.co.jp/how_to_accele

Githubのcontributionsがハロウィン仕様になってる!!!

SRAU Factory さんがブースト

いつもPawooをご利用いただきありがとうございます。
PawooのiOS・Androidアプリについて、ブラウザ版との機能の違いが広がってきている状況を鑑み、この度サポートを終了する運びとなりました。
※現在インストールされているアプリは引き続きご利用いただけます。

スマートフォンからPawooをご利用になる場合は、ブラウザ版または他のマストドンクライアントからご利用いただけますと幸いです。
今後ともPawooをどうぞよろしくお願いいたします。

まさかのPawoo終了 ?!
Tootter派なので、影響はないですが。。。

SRAU Factory さんがブースト

昔関わってたSNSで投稿の禁止ワードがあったけど、サイコロステーキが「コロス」に引っかかって投稿できないとクレームが来たことがある

システム担当者「合コンって検索しましたよね?」→総合コンサルタント 前後を見ずに『不適切なワード』だけ拾い上げるシステムだとこうなる
togetter.com/li/1280860

当方、各クラウドソーシングサービスにアカウントがあり、
そこで案件を受注したりすることもあるのですが。

さっき案件をいくつか見ていたら、
Webの開発案件なのですが、
「〇万円で御見積をお願いします。」
と記載されているのが結構ありました。

いや、その見積の金額を決めるのはあなたではないのですが。。。

最近、システム開発の案件を受注していても、
発注先がシステム開発の発注金額を先に決めていて、
その金額に見合わない物を作らされるケースが多い気がします。

システム開発を安易に値切るのは、後ほど高く付くので、絶対に止めた方が良いです。

これサービス開発だとよくあるやつですよね。
(今の案件はまさにこの事例の最後のパターンです。。。)

リリースが頻発すると、ブランチの管理も複雑になりますよね。
なる早で改善を、
というのは分からないでもないですが、
無理していると運用が回らなくなるため、
どこかでしっかり整理する必要がありますよね。

ブランチ運用の見直しと自動化で、モバイルアプリ開発における問題を解決! (1/2):CodeZine(コードジン) codezine.jp/article/detail/110 @codezineさんから

SRAU Factory さんがブースト

@sraufactory はい。。コスパ悪いようにもみえますが、繰り返していくとだんだんと早くなりますね。ドキュメントに書いてたとしても文章理解には時間がかかるもので、結局の所集まって説明しあって、理解速度自体をあげていくのがいいかなぁというかんじですね><

SRAU Factory さんがブースト

自分が今おつきあいしている方。
もう5年はつきあいしているだろうか (もしかして、もっと前から?)。

その方のことをよく考える。
癖を覚えて、「こういうときはこうされるのか」というのを日々気づいて記録するようにしている。

毎年新しい方も出るけど、今の方と今後もおつきあいしたいとは思います。

**注記**: 開発環境(IDE)の特定のバージョンのことです。



SRAU Factory さんがブースト

「特に具体的なあれはないけど素晴らしいエクスペリエンスを持ってるね!!!一度話さない???」みたいのまじいい加減にして欲しい

ちなみに本日、まさにこの共通認識の問題で、
担当している案件でも同じようなことがありました。。。

結果、理解の間違いというところに落ち着くまでに、
だいぶやりとりが必要でしたが。。。

コードレビューってどのプロジェクトでもやはり難しいのね。。。

特にプロジェクトのメンバーが多くなると、難しくなる傾向があります。

メンバーが小人数の時は、
自分以外のメンバーのコードの書き方も補完できるし、
意思疎通もそんなに複雑ではない。

しかしメンバーが増えると、
コミュニケーションパスが増えることや、
意思疎通や仕様徹底が難しい場面が増えます。

そのため、このような自体になることが多いんですよね。

大事な言葉・HRT~「Humility(謙虚)」、「Respect(尊敬)」、「Trust(信頼)」。ああなんて難しい by developer-kikikaikai qiita.com/developer-kikikaikai

ノートは昔は罫線派でしたが、最近はもっぱらデジタル(Evernoteやメモアプリ、リマインダー等)なので、あまりこだわりがない。。。

でも紙なら無地の方がいいかもですね。
画面イメージ書くときに罫線が邪魔になったりするので。