"運用/保守"投稿一覧

私自身、色々なフリーランスエージェントの方とお話しましたが、やはり実務経験が大事との事でした。
エンジニアの方でしたら、多少なりとも経験があるかと思いますので、今やっている言語を最低でも2年くらいやっておいた方が、書類選考にも通りやすいらしいです。
非エンジニアの方でしたら、何かしらフロントエンド（画面側）とバックエンド（裏で動く処理）とDBを使って、簡単でもよいので、小さなシ... 続きを見る

同じような質問に対しての回答がございますので、こちら参考になれば幸いです。


https://offers.jp/qa/question/Ui2zT0Ogdi/... 続きを見る

どういう形とどういうレベル感のプロダクトにジョイんするかによりますが、基本的にはバックエンドに関しては自分で全て作り切るくらいじゃないと案件を取るのは難しい気がします！

僕が考えるレベル感になりますが
- 要件定義されたものを作るだけ 5000円/h
- 要件定義されたものを作れる&パフォーマンスチューニングやそれを考慮した設計ができる 6-700... 続きを見る

前日までの Pull Request のコードレビューをするところから1日を始めることが多いです。
午前中にマネージャとの 1on1 で今抱えている課題や本日の作業目標を共有します。
その後 Slack のハドルでコードの疑問点を相談したり、モブプロを行うことが多いです。
お昼はご飯を食べながら勉強会に参加します。
午後は自分の作業に集中して夕食までデバッグ... 続きを見る

kotlinを初めて1年半くらいになります。元々はJavaエンジニアでJavaは20年以上の経験があります。
なのでJavaとの比較になってしまますが。
kotlinは当初はAndroidアプリ開発用としてスタートしましたが、今はそんなことはありません。

Androidアプリ開発の他、
サーバサイドアプリ(Spring Frameworkもkot... 続きを見る

こんにちは、現在、C言語、C++言語をメインに開発をしております。
Windowsであれば、Microsoft Visual Studioが良いのではないでしょうか？シェアが多く不明点等が発生した場合に、情報入手はしやすいと感じています。
あと、Visual Studio Codeであれば、OSに依存しないため、Windows、Mac、Linuxどれでも使用可能です。 続きを見る

古い事例ですが、PlayStation のソフトでいくつか GPL 違反事例があったのを思い出したので、改めて探してみました。

ToHeart2 など (2005年)
続きを見る

一応、ベストプラクティスと銘打ったものはあります。
以下記事でそれを整理してくれています。
https://dev.classme... 続きを見る

質問内容から推測するに、自社のエンジニアが誤ってコードやシークレットキーを公開してしまうことを懸念されているのではないかと想像しました。「GitHub コード 誤って公開」といったキーワードでGoogle検索すると、たくさんの事例がひっかかります。もちろん、これはGitHubの利用者が多いことの裏返しでもあるのですが。また、GitHubの利用者が多いが故に、コードをpublicなリポジトリで公開す... 続きを見る

基本的なコマンドの定義次第ですが、挙げられてるものが扱えるのならあまり困らないのではないでしょうか。

Dai Fujihara さんが挙げてらっしゃいますがサル先生のGit入門は私もおすすめですし、
かなり古い記事ですが以下Qiita記事も読みやすくわかりやすかったのでここで挙げられてるコマンドあたりもおすすめです
デザイナーがこうやってGit覚えて大好き... 続きを見る

昔、Gitがはやりはじめたときにいくつかチュートリアルがでてましたが、そのなかで開発メンバー全員で学んだりしたのがこちらです。

サル先生のGit入門〜バージョン管理を使いこなそう

あくまで私見ですが回答いたします。

・PMF前のスタートアップでの主要なセキュリティリスクは何ですか？

SaaSであればWEBセキュリティを破られること。
また取引先や投資先、あるいはアルゴリズムなどの機密情報が漏れることです。

・限られたリソースで効果的なセキュリティ戦略を構...

続きを見る

ひとつの指標として、情報セキュリティマネジメントシステムの規格である JIS Q 27001:2014(ISO/IEC 27001:2013)  の取得をご検討してみてはいかがでしょうか。

h...

内製でやっていますねー。
最近は AWS Fargate など、あんまり自分でサーバー管理を意識しなくていいものが増えているので、
そういったものを採用してプロダクト開発にかける時間を増やすのが、いい選択と言えるかもしれません。

たくさんアウトプットできればそれはそれでいいと思いますが、必ずしもそうはいかず量は絞られますので、なにかに特化してアウトプットするのが良いと思います。

適当に色々アウトプットしていると、なんかよくアウトプットはしてるみたいだけどなんの人かはよくわからない、となりがちです。特定の言語やフレームワークについて集中してアウトプットするとこの人はこれをやってる人、というのが明確になり... 続きを見る

僕は本業とは別に個人でのアプリ開発も行なっています。
現在ユーザーにより良い機能を届けることに注力しているため、僕のアウトプットは個人アプリの開発になります。

少し前までは、Qiitaやブログでの記事発信を行なっていましたが、ユーザーに喜んでもらえることの方にコミットしたいなという心境の変化があったため技術記事の発信という意味でのアウトプットには時間を割けていません

私はコンサルなのでコンサル的な手法で失礼します。

クライアントサイドに立ってみると、失敗しているのは全員が自覚していますし、とは言え昔のこととは言え先輩の責任を明確に言葉にしたらそれを理由に足を引っ張られたり、と言うのが派閥のある大企業です。

そして、わからせるとありますが、これも無理です。気づかないで放置してた責任を問われているやうなものなので、うまく... 続きを見る

レガシーなシステムの相談はよく受けています。ただ、仕事になるか？というとそうでもないなぁという印象です。なぜなら、問題が難しいからだと思います。外部からとやかくいうのは簡単ですが、現場には現場なりの問題があります。これを理解して、良い方向に持っていくのは、おっしゃるように骨の折れる作業です。

ただ、仕事上、どうにかして良くしたいので、いくつかアプローチとしてやっていることはあ... 続きを見る

対応しないことに伴って発生する損失を数値にして明確に示してあげる必要は最低限あるかもしれません。これをやらずにそのままやるのと、やってからやるのは費用的に、時間的にこれだけ異なる、という部分です。
また求人の難しさ、人を入れてもやめていってしまう可能性の高さなどでわかりやすく。
（と言ってもだめな場合も多いと思いますが…）

20年のキャリアから申し上げますが日常的なサーバ管理業務はほぼリモートに移りつつあるという結論しかありません。かつての私の理想はほぼ実現してしまいました。コレから益々そうなるでしょう。はいおしまい。ただ未だ完全リモートなる現実はなく、未だ少しずつ出社して作業しなくちゃならない面倒は残るとは思いますが。

ハードウェア保守は集約度が上がり、クラウドに移行した事で現場経験者は限られ... 続きを見る