「バージョン管理システム」を含む日記 RSS

はてなキーワード: バージョン管理システムとは

2024-06-09

リーナス・トーバルズ暗号通貨詐欺的だと考えている

分散バージョン管理システムGit開発者でもあるトーバルズ氏は、暗号通貨サンタクロースイースター・バニーと同じ神話カテゴリー位置づけているとユーモアを交えて付け加えた。

彼のコメントは、ビットコイン曖昧創設者であるサトシ・ナカモトではないかという間違った憶測を含む、技術コミュニティでの議論の中で生まれた。

トーバルズ氏はこのような噂を否定し、Linuxカーネル編集自分名前がユーモラスにビットコインと結びつけられたことを明らかにした。トーバルズ氏は、自分ビットコインの多額の財産を所有していないと断言し、そのような主張の信憑性については否定であるとの立場を繰り返した。

ソース: https://www.realworldtech.com/forum/?threadid=217627&curpostid=217694

2024-05-19

著名ソフトウェアエンジニア入社して3週間経った観測結果

前提

私はWebアプリケーション開発に関わっているエンジニアであり、社内の多くのエンジニアWebネイティブアプリの開発に従事しています会社の規模は日本国内で言えば大きい方です。

そんな会社で働いている中で、最近著名なエンジニア入社しました。私はその方をSNSなどで拝見しており、どんなアウトプットを出すのかとても楽しみにしていました(ただし、その方は私とは関わりのない部署に配属されています)。しかし、3週間が経過した現在もやもやすることがあり、この日記を書いています

何がもやもやするのか

まず、前提として、入社して3週間でアウトプットを出せる人は世の中にそう多くはないと思っていますし、それが高い職位で雇用されているなら尚更だと思います。なので、3週間経って何もアウトプットがないのは仕方ないことだと思いますシステムに関する知識解決したい課題要件仕様関係者、社内事情技術領域などなど)がまったくない状態で、そのキャッチアップに時間がかかるのは誰しも同じだと思います

しかし、この3週間でその方がどういうアウトプットをするのか見たかったので、バージョン管理システムログや社内チャットツールで色々と確認してみると、どうもその方は外部の登壇資料を作ることしかしていないようでした(実際には自社の仕事もしていましたが、登壇資料が9割を占めているように見えました)。

この行動に対してもやもやすることがありました。それは、「まず自社に貢献しないのか?」「登壇料をもらっているならそれは副業範囲内であり、プライベートでやるべきではないのか?」です。その方がどういう期待値入社しているのか分からないので、もしかしたら登壇も仕事の一環なのかもしれません。それでもももやしますそもそも、自社の利益にその登壇は本当に貢献するのか?というところです。外部に登壇するくらいなら、自社向けに発表と質疑応答を行い、社内エンジニア能力向上に貢献するほうが良いと思います

よくある反論として「自社の宣伝になるから良いのでは?」というのがあります。それも理解できるのですが、それは自社で得られたノウハウ宣伝する場合に当てはまると思いますしかし、その方は入社ほとんど自社のシステムに関わっていないので、その反論は当てはまらないと思います

また、副業として登壇料を受け取っているようです。自分には直接の害はないのですが、これって会社から給料をもらっている時間副業していることになり、副業規定抵触するのでは?と思いました。私自身も副業ソフトウェア開発をしていますが、本業時間副業をしても良いのだろうか?と疑問に思いました。また、それが普通に許されているのもなんだかなーと思いました。まず、自社に貢献しろよ、と。

私がすごいと思うソフトウェアエンジニアは、やはり自社の課題スマート解決する方々だと思います。ですから、登壇ばかりしているエンジニアに高い給料を払っているのがもやもやします。

最後に、その方の職歴について思ったことがあります。あまり詳しくは書きませんが、おそらくそれなりに高い職位(テックリードなど)で雇用されていたと思います。職位が高ければ高いほど、成果を出すのに時間がかかると思いますが、その方は結構なペースで転職しています。それ自体は構わないのですが、もしかして自社に貢献できず、居場所がなかったのでは?と勘ぐってしまます。この勘ぐりを加速させる材料として、その方の登壇や記事にはほとんど自社の話がないこともあります

実は他にも色々ともやもやすることはありますが、このくらいにしておきます(登壇内容などにも疑問はありますが、それは個人自由なので)。

学び

まとめ

まだ3週間しか経っていないので、これからどうなるのか分かりませんが、引き続きウォッチしていきたいと思います。離れた部署にいる人間から見えていることなので、細かいところは違うと思います(思いたいです)。これからどうなるのか、楽しみです。

2024-05-01

[] It doesn't work...why?

ソースコードに間違いが見つからないのに想定される出力をしない。あるいはソースコード修正を加えていないのにいきなり想定出力を返すようになった。」

こういう経験がある人はいるはずだ。なぜこれが起こるのか。一つの原因を見つけた。

それは環境変数設定ファイル存在する。デプロイ時には設定ファイル特定の値に修正してから、ということがあるだろう。

開発環境コーディングする人が、デプロイ時の設定ファイルには関与せず、デプロイ担当者がそれを把握している。

開発者セキュリティ上の理由デプロイ時の設定ファイルの内容を見ることができない。

この場合設定ファイルの内容が間違っていても、開発者が原因が正しく特定できないケースがあるのである

対処方法は以下である。まず事前にやっているであろう対処は以下である

事前にやっていない可能性がある対処は以下である

 

追記:

他に遭遇したケースは、環境アップグレードによってphp特定関数廃止したというケースだ。

インフラ要員がアップグレードを行うので開発者は原因がわからなくなる。

2023-12-17

anond:20231216154938

コードの重複があるわけでもない状況で、コード関数ごとに分離するメリットデメリットを知りたいという話ですよね。

コードの重複がある場合関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。

画面に収まらないサイズコード複数関数に分割するのが一般的だとは思います

理由元増田も書かれている通り、長いと理解の限度を超えるからです。

コード意味があるまとまりで短ければ短いほど理解がしやすいと思います

グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さら理解がしやすいです。

また、関数に分けておけば、関数仕様通りに動くかの確認するユニットテスト簡単に書けます

ユニットテストでは関数さらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります

分割して、複数関数を呼び出すようにすることのデメリットは、

下手糞が切り分けるとなんでそういう切り分けになったかからないところで切り分けられてかえって可読性が損なわれるとか、

関数機能拡張してより多く・あるいは少なくの情報必要な時に関数インタフェースの変更が必要になることとか、

関数を置いているファイル内の場所を変えたときバージョン管理システムが追っかけてくれないことがあるとか

くらいでしょうか。

いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います

以下、お悩みポイントに答えます

一番はメイン/サブ関数間で右往左往するので今やってる工程が何なのかがよくわからん

まず、関数名前をやっている工程を表すものにすることですね。

データの取り込み」 とか 「データ突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。

また、関数が何をしてくれるのかも関数コメントとしてつけておくとよいと思います

例えば、

filename引数指定されたファイルからデータを取り込み、JSONフォーマットで返す

引数: filename

返値: JSONフォーマットされた取り込まれデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]

例外: filenameを開けない場合はFileOpenError、JSONコンバートできなかった場合はConvertError

みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。

あと、コード連続で読みたい場合ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います

あとは関数ごとに変数をいちいち定義し直すのがだるいみたいなのもありますね。

これはどういう意味でしょうか?同じものを表すのに関数ごとに別の変数名を付けているとか?

もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか?

ある関数ローカル変数が他の関数ローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当名前が付けられるイメージです。

今時のプログラミング言語なら変数スコープ関数の中にとどまるような書き方ができると思うのですが。

関数インタフェース定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。

そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。

参考までに。

2023-10-29

達人プログラマーゾルラーク

anond:20231027224113

プログラミング話題と相性がいいんじゃないかと思って、昔読んだことがある達人プログラマー (1999年出版された第1版の方、2019年出版された第2版ではない) をぱらぱら見返してみた。プログラマーとしての姿勢プラクティスなどは一般に普及したかどうかの判断が難しい。間違いなく一般的になったなと思えるものに絞って書く。インフラ面の進化が大きいと言えそう。

フリーレン「わずか数年で人類の開発方法論に組み込まれ、新しいインフラによってシステム開発生産性を向上させた。」

17 ソースコード管理

でも今のチームはソースコード管理システムを使っていないんだけど…

恥ずかしいと思ってください! そして、これが伝道師となる機会だと受け止めてほしいのです。しかし、彼らが自ら進むべき道を見つける時まで、あなた一人ぼっちであってもソース管理を使うようにしてください。

フェルン「いまのはバージョン管理システムです。」

33 リファクタリング

いつリファクタリングを行うべきなのか?

コードがうまくなじんでいないと感じたり、まとめるべき 2 つの事柄を見つけたりといった何か「おかしもの」に遭遇した場合、手を入れることを躊躇してはいけません。

34 テストやすコード/43 容赦ないテスト

テスト文化

あなた記述したソフトウェアはすべてテスト対象になりますあなたあなたのチームの人間テストをしなければ、最終的にユーザーテストを強いられるのです。このため、テスト計画を徹底的に練る必要がありますしかし、事前にものごとを少し考えるだけでメンテナンス費とヘルプデスクへの呼び出しを大幅に削減できます

(中略)

テスト技術というよりは文化なのです。こういったテスト文化は、使用する言語関係なくプロジェクトに植え付けることが可能なのです。

フェルン「いまのはテスト駆動開発です。」

42 どこでも自動化

多くのプロジェクトでは、こういったレベルビルドは毎晩自動的に実行されています。つまりプロジェクト特定部分を夜間ビルド作成すると同時に、個別テストよりも完全なテストを実行できるのです。これによって、完全なビルド実行時に行うテストをすべて実行させることも可能になります。結果として、その日のうちに回帰テスト問題を見つけられるようになるわけです。ソースの変更後、できるだけ早い時点で問題を検出できれば、バグの検出と修正を円滑に進められるようになるはずです。

フェルン「いまのは CI/CD です。」

2023-07-11

Unityゲームエンジンを主に使ってるエンジニアの方に質問です。

Unity5から長く離れていたほぼほぼ今となっては初学者とみなしてよい者なのですが、

開発環境最初から選定すべきライブラリベストプラクティスについて教えて欲しいです。各々のオレオレベストプラクティスで良いです。

 

想定されるテンプレ

Unityバージョン:

コーディングエディタ:

バージョン管理システム:

入れておくべきライブラリ:

入れておくべきアセット:

 

みたいな感じです。

例えば

 

Unityバージョン: 2022 LTS

コーディングエディタ: VSCodeになんかよさげプラグイン

バージョン管理システム: Git

入れておくべきライブラリ: UniRx,UniTask

入れておくべきアセット: 画像音楽3DモデルというよりはRewiredなどのロジックを補強するアセットなどが知りたいです

 

こんな感じでしょうか。

あとはいい感じのチュートリアル記事などがあればうれしいです。

2022-08-31

anond:20220831183013

とりあえず上にインシデントを報告するために報告書を書いてもらったんだけど、「NGワードを削除しました」だけだと上の人に詳細に伝わらないので削除した単語一覧と削除した理由も追加しておいてねって報告書添削をしたら数日後に人事から呼び出しを食らった。

ここれまでの段落の内容と、そもそも本文全体からして増田本人がapproveするとは考えられないから。

インシデント報告」「削除しました」って書いてあるから上記引用した段階ではすでに事後。

となると、masterにpushできたに違いない(PR経由のmasterマージも、自分で無条件マージできるならばmaster pushと一緒)。

また、前段の方で「そのNGワード集に編集リクエストみたいなの」と、「編集リクエストみたいなの」と言っていることからバージョン管理システムなりの使い方をよくわかっていない可能性が高い。

ふわふわした形でバージョン管理システムを使っているならば、すべての人に全権限を与えていたり、masterマージ時にレビュー必須にするなどの条件が設定されていないということはあり得る。

2022-08-02

[]Git

Git(ギット[2][3][4])は、プログラムソースコードなどの変更履歴を記録・追跡するための分散バージョン管理システムであるLinuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクト採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在メンテナは濱野純 (英語: Junio C Hamano) で、2005年7月から担当している。

Gitでは、各ユーザワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークアクセスできないなどの理由で中心リポジトリアクセスできない環境でも、履歴調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である

2022-07-26

GAFAMで言えない言葉

みんな大好きGAFAMはご存知の通り言論統制が大好きだよ!言論統制ユーザだけでなく社員にも課しているよ!どんなことが言えないのか紹介していくね!

追記差別用語としての地位確立していない言葉に敏感になりすぎるとより差別と分断を助長していくよ!これらは包含言語と呼ばれるけれどもむしろこのような過敏な言い換えを知らないと差別主義者としてのレッテルを貼られるなど階級差別的で排除主義的な行いにしか用いられることは無いよ!つまり本来目的を全く達成しないばかりか分断をより強くしていくよ!更に二重基準も酷いもの論理なんてもの存在しないよ!これらの言葉推し進めている人達自分たち正義の行いをしていると思い込んでいるので余計にたちが悪いよ!

2022-05-21

Web3を理解できない奴はバカって言う奴こそバカ

結局さ、Web3で何ができるのか提唱者も含めて誰も明確に語れていなくてWeb3っていう言葉けが1人歩きしている状態じゃんね?

ブロックチェーン既存Webを置き換える、既存Webアップデートするっていうけどさ、既存Webって大半がランダムアクセスじゃん
ブロックチェーンランダムアクセス性能が改善されていってるという主張があるのは知ってるが、ブロックチェーンの基礎部分はシーケンシャルアクセス念頭に置いたもんじゃ
どうやっても既存リレーショナルデータベースランダムアクセス性能を追い越すことはなく、ブロックチェーンランダムアクセス性能が現在リレーショナルデータベースと同等になった頃にはリレーショナルデータベースは更なるランダムアクセス性能の向上を果たしてると見て良いだろ
ブロックチェーン永遠にリレーショナルデータベースを超えられないじゃん

NFTだって結局のところブロックチェーンではクソデカバイナリファイルを扱うのは無理があるって言うんでURLみたいな小さなテキストデータ実体管理しようというGit LFSと似たような運用の仕方なわけだろ?
クソデカバイナリファイルを扱えずにどうやって既存Webを置き換えたり、既存Webアップデートするんだよ
いやそうじゃないんだ、もっと良い方法あるんだと、そんなものがあるなら先にバージョン管理システムがやっとるわと

全くもって理解できないんだよWeb3って一体なんなんだよ
IT技術者の理解放置して投資投棄やってる連中の中だけで進んでいくIT技術ってそんなもの成立すると思ってるのか?
そして返ってくるのはお決まりの「お前がバカからWeb3を理解できない」ですよ

はああぁぁぁァァァ!!!?????!!!!!!??????

2021-08-16

【未経験から1ヶ月で】現役エンジニアが教える最良のプログラミング勉強法

プログラマーに憧れる皆さん!こんばんは。

自分文系から」「未経験から」と諦めていませんか?大丈夫です!プログラミングセンス不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます

今日は、未経験から最短でWeb企業就職するための勉強法をご紹介します!

オススメ方法

もっとオススメ方法は、顕正会セミナーに参加することです。

顕正会は、日本で最大のエンジニアコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアノウハウを学ぶことができます

また、意外と知られていませんが、日本エンジニアの8割は顕正会出身です。実はあのひろゆきビル・ゲイツ顕正会出身です。ですので、顕正会ネットワークを介して就職先を斡旋してくれたりしますし、自分顕正会員だと、面接時にも非常に有利になります

顕正会セミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい!無料体験もできますよ。

準備

プログラミング勉強を始める前に、まず、必要ものを準備しましょう。必ず必要ものと、できればあると良いものは以下の通りです。

必ず必要もの

まず、プログラムを書いて実行するためにパソコン必須です。

可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッドRAMは128GBくらいはあると良いでしょう。ストレージSSDであれば1TBもあれば十分です。

OSは、Windowsで開発するならWindowsが、Macで開発するならMac必要です。よく分からなければMacを買っておく方が良いでしょう。基本的MacにできてWindowsにできないことはありません。

インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。

顕正会に入会すれば、上記スペックPC無料で貸し出ししてくれます。また、法人向けの専用線無料で取付工事を行ってくれる上に、通信費を全て負担してくれます

できればあると良いもの

まず、他の会員と連絡を取るために、SNSアカウントを持っていると良いでしょう。

最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的ものを覚えることができます

Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITプロを目指そうという人間が、このような最先端デバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります現金も持つのはやめましょう。

自宅での学習

せっかくセミナーに参加しても、受身聴くだけでは、プログラミング習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。

教科書写経する

まずは、教科書参考書写経することから始めましょう。教科書参考書の本文を一字一句正確に書き写すのです。

よく、「写経理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈自然と身に付きます

また、写経メリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばししまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。

ソースコードフローチャートUML)に変換する

教科書サンプルコードノートに書き写したら、それを今度は自力フローチャートUML)に変換してみましょう。そうすることで、自分が本当にそのコード理解しているのか、確かめることができます

フローチャートUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要スキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業顧客にとっては貴重な資料となるからです。プロエンジニアは、COBOLソースコード10万行を1週間でフローチャートにして、Excel転載することができます

ここで一つ注意すべきことがありますフローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたもの業務ではフローチャートとは認められません。これはまともな企業就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。

Excel勉強する

エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業Excelで行いますセル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。

プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。

尤も、以上の資料は、ツールを使うことで自動作成することもできます。たとえば、ソースコード更新履歴Gitなどのバージョン管理システムを使うことでも管理できますしかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう!VBA習得必須です。

プログラミングのコツ

以上、プログラミング勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。

変数名は短く

プログラムで使う変数名は可能な限り短くしましょう。

理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。

また、変数宣言使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分ミスしにくくなります

変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。


なるべく関数を作らない

多くのプログラミング言語には、クラス関数といった機能がありますが、これらは基本的ライブラリ提供者などが使う想定の機能であり、一般プログラマが使うのは好ましくありません。したがって、クラス関数はなるべく使わないようにして下さい。

関数を作ると、以下のデメリットがあります

不要関数を作らないためのテクニックには、以下のようなものがあります

まず、関数引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数複数の処理をすることができます

function f(i) {
  switch(i) {
    case 1:
      // i = 1のときの処理
      break;
    case 2:
      // i = 2のときの処理
      break;
    case 3:
      // i = 3のときの処理
      break;
    // ...
  }
}

この方法は、以下に述べる「変数寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます

クラス不要関数を作らないようにするには、「継承」を用います複数クラスで用いる関数定義したクラスを1つ作っておき、そのクラス継承すれば、新しいクラス関数定義する必要はありません。

理想的には、プログラム内のすべての関数を同一のクラス定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています

class God {
  f1() {
    // 関数1
  }
  
  f2() {
    // 関数2
  }
  // ...
}

class C1 extends God {
  // 何も書かなくても上の関数が使える!
}

class C2 extends God {
  // 何も書かなくても上の関数が使える!
}
// ...

変数寿命を長くする

変数宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数寿命が長い」と言います

たとえば、以下のコードのaは、関数定義の外側からは参照することができません。

function f() {
  var a = 1;
  return a;
}

一方、以下のコードのaは関数の内外どちらからでも参照することができます

var a = 1;

function f() {
  a = 2;
  return a;
}

変数寿命を長くするのは、プログラマの腕の見せ所です。

せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまます

また、変数寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数寿命を長くするとプログラムを変更しやすくなります。つまり保守性が上がります

例外を潰す

例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイル存在しない場合は、例外となります

例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマ例外をきちんと処理しなければなりません。

ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。

try {
  // 例外が発生し得る処理
  // ex. ファイルを開く
}
catch (e) {
  // 例外が発生したときに、実行する処理
}

例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラム動作を続けます

try {
  // 例外が発生し得る処理
}
catch () {}

全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから例外が発生し得るコードは、積極的上記try-catch構文を用いて、例外を潰すようにしましょう。

おわりに

全体的に専門用語盛りだくさんの記事になってしまいましたが、

部分的にでも理解すればプログラミングを見る目が変わるはずです。

うさんくさい記事インターネットには多いですが、

そういう情報に惑わされずに本物の技術を身につけてもらえればと思います

2021-07-17

anond:20210716192706

仕事がぬるいのはある意味楽に金もらえるからいいんだけど、バージョン管理システム使ってないところが多すぎなのをなんとかしてほしい

2021-01-07

gitスナップショットを保存するだって

https://b.hatena.ne.jp/entry/s/github.blog/jp/2021-01-06-commits-are-snapshots-not-diffs/

複数差分からスナップショットを取り出すことは必ず成功するが、

複数スナップショットから差分を取り出すことは失敗する場合がある。

gitファイル名変更とファイル内容変更を同時に行ったときに、

変更履歴が追跡できなくなる事があるのがこのパターンである

 

まりコミットスナップショットとして保存する設計には実害がある。

 

かにスナップショット方式であればバグによっって特定コミット内容が失われた時に、

以降のコミット内容を失わずに済むメリットはある。

しかバージョン管理システムは通常そのようなバグが発生しえないほど安定した状態で使われるため

これは利用段階においては実質的メリットにならない。

その上gitでもレポジトリ容量削減のために、記憶媒体上に保存されるデータ差分なので

上記メリット享受できない場合がある。

 

初期のプロトタイプ版開発のためにはスナップショット方式有効だったかもしれないが、

リリース版でもその方式を利用し続けたのはgit設計上の欠陥であり、

リーナスは間違えたと言っていい。

 

 

 

……と思うのだが、これに対してスナップショット方式擁護する意見ってある?

2020-11-21

ソースコード品質を保つために真に効果的な手段は3つしか無い

  1. バージョン管理システムを使う
  2. 静的型付け言語およびlintを使う
  3. テスト駆動開発をする

どんなに優れたツール設計思想などがあっても、使う奴がダメだと全く無意味。弊社もWebアプリを作ってて、RESTだのFluxアーキテクチャだのいろいろ導入を試みたが、ほとんど無駄に終わった。

どんなクソ組織でも効果があると確信持って言えるのは上の3つだけ。1つ目は初歩的すぎると思われるかも知れないが、筆者の想定するダメ組織ダメプログラマというのは、このレベルの連中を含む。

とにかく最低限の品質保証強制する仕組み以外は無意味

静的型付け言語サーバーサイドならJavaC#フロントエンドならTypeScript)を使わせれば、少なくともコンパイル時に分かるエラー修正させられる。

というか、ダメプログラマに動的型付けの言語は触らせてはいけない。必ずそのプロジェクト半年後には保守できなくなる。

テスト強制的に書かせるし、テストのないクラスや、通らないテストあったらコミットできないようにする(それは容易にできる)。

番外編: ものすごくマイナー言語を使う

もう一つの方法は、そもそも優秀なエンジニアしか参加できないようにすること。たとえば、ScalaHaskellErlangCommon Lispなどで書かれていれば必然的にそれが分かるエンジニアしか開発できないし、こういう言語自主的学習しているエンジニアは優秀である可能性が高い。

2020-11-16

本当は「小説バージョン管理したい」わけではない

結論最初に書くと、作家がやりたいのは「小説バージョン管理」ではなく「出版プロジェクトタスク管理」と「成果物品質管理」なのである

数年前に「家事Redmine管理すると捗る」という記事流行ったように、それと同じことが作家界隈でも散発的に起きていると考えたほうが実情に近い。

WordやG Suiteの校正機能じゃダメなの?」に対する返答は「WordやG Suiteにはタスク管理ツールが付いてないかダメ」。

本当はGitHubである必要はなく、RedmineTracWordを組み合わせてもいいのだが、「ハンマーを持つ人にはすべてが釘に見える」のでGitHubのためにGitを使おうという本末転倒議論になりがちな印象がある。

逆に「バージョン管理はあるがタスク管理品質管理がない」環境の例としてはウィキペディアMediaWiki)がある。

MediaWikiはすべての版をバージョン管理しており、差分履歴も見られるが校正にはあまり向いていない。ウィキペディア文章があまり洗練されないのは支援ツールの不在による部分が実は大きい。

結局のところ作家必要なのは

の2つで、それを下支えするためにバージョン管理システムは必要だがGitほど多機能である必要はない。むしろRCSくらいシンプルなほうが理解されやすいのではないかと思う。

2020-11-02

「達人プログラマー」は本来読む価値の無い本

「達人プログラマー」は名著と言われるが、この本に書いてあることは、

といった、一定水準以上のプログラマにとっては当たり前のことばかりである。だから、まともなプログラマはこの本を読む必要は無い。

1999年出版されたこの本が今なお価値を失わないのは、要するに大部分のソフトウェア開発の現場で、上に書いたような当たり前のことが守られていないかである

この本が推薦され続けることは、ソフトウェア産業が技術的にも常識的にもいかレベルが低い業界であるかを物語っている。

2019-01-22

プログラマ業務中に身につく知識

業務ではこんなことやるんだな。テストってこういうことか。ここは案外適当なんだな。この製品プログラムはこんな感じのプログラムになってるんだな」ってことが業務でわかる。だけど言語とかフレームワークとかの仕様業務では別に身につかない、なぜならそういうのはほぼOJTから(聞けば答えてくれるシステム)。

最初研修言語フレームワーク一つずつでも覚えさせてもらえばだいぶありがたいと思うけどそういうの無い場合本当にそういうのは独学になる。家に帰って。または先輩にたまに聞くとか(ちょびちょびと…)。そんなんなら知恵袋で聞くのと変わらないし。

業務で学べることはただただ「これは実際こうやって動いてるのか」って中身が見れること以外は少ないと思う。言語フレームワークサーバーバージョン管理システムとかは自分で覚えないといけない。というか覚えられない。時間かかる。働いてる中での独学なんて時間そんな無いし。

2019-01-20

勤務先のSIerなのですが、

Vi誰も知らないので利用するのに稟議必要しか却下される。

・標準ライブラリ存在をだれも知らないので誰も使っていない。使用するとキレられる。

バージョン管理システムを誰も触ったことがない。存在すら誰も知らない

コンパイルビルド、だと伝わらない。再生ボタン、もしくは実行ボタンと言わないと誰もわからない。

助けてください…

2018-10-02

anond:20181002221649

伏せ字意味ない。

それはそうと、バージョン管理システムが無いとか、エクセル仕様書とか、そんな会社普通にあちこちにありそう。

2018-07-14

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

1.

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

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

かい仕様も載っていない

1.

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

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

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

1.

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

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

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

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

2018-06-28

ローカル小規模商店のためにテキストサイトを再評価する

経緯

食べログWeb制作企業アコギ商売のため、それらに不満を抱えているローカル小規模商店が多いとわかった

そこで(抜けはあるかも知れないが)一部の知識提供しようと思う。

前提として「すべてこの情報でまるっと上手くか?」といえば「そうてないこともある」ことは留意しておいて欲しい。

この情報に向いている商業

この情報に向いていない商業

プロバイダ100MBホームページスペースのメリット

プロバイダ100MBホームページスペースのデメリット

静的サイトジェネレータ

流石に今どき!DOCTYPEから手打ちしろというのは酷すぎるので「静的サイトジェネレータ」を使う

わかりやすく言えば「ホームページビルダー」で、デザインテーマに合わせたWebページの雛形を生成してくれるもの

現在では静的サイトジェネレータと言うとGUIではなくCUIからWebページを生成してくれるものを指すことが多い

GUI場合は「Webサイト作成ソフト」「Webオーサリングツール」と呼ばれることが多い

生成されたWebページが含まれディレクトリFTPアプリケーションプロバイダホームページスペースへアップロードするだけでWebサイトを立ち上げることが可能

早い話こんなのが簡単に作れる上に、最初からたいていはスマホにも対応してる

ttp://www.codeblocq.com/assets/projects/hexo-theme-magnetic/

ttps://sharvaridesai.github.io/hexo-theme-edinburgh-demo

ttps://themes.gohugo.io/theme/yourfolio/

ttps://themes.gohugo.io/theme/alpha-church/

ttps://themes.gohugo.io/theme/hugo-shopping-product-catalogue-simple/products/

ttps://themes.gohugo.io/theme/hugo-creative-portfolio-theme/portfolio/

ttps://event-jekyll-theme.github.io

ttp://jekyllthemes.org/themes/project-gaia/

ttps://portfolio-central.github.io/jekyll-instagram-portfolio-theme/

ttp://mushishi78.github.io/one-page-wonder-jekyll/

ttps://jekyller.github.io/online-cv/

ttp://webjeda.com/bheema/

静的サイトジェネレータとして日本で有名なものは下記

「久々にその固有名詞見たわ」「古いバージョンなら持ってる」と言われそうなド定番

仕事普通に使ってる」と言われそうなコレまたド定番

  • BlueGriffon(GUI)

オープンソースWebオーサリングツール無料だけどホームページビルダーやDreamweaverに比べると使いにくい

日本情報豊富Ruby製静的サイトジェネレータ。他者質問やすいというメリットもある

Node.js製の静的サイトジェネレータ。もう既にNode.js環境があるならアリかな?

Go製静的サイトジェネレータ。シンプル機能Webページ生成までの高速性が売り

「どれが良いか?」と問われると「どれが良いってことは無いんだけど、情報豊富さならJekyll、Webページの生成の速さならHugo」というのが答え

合わないと思ったら別の使えば良いとは思う

FTPアプリケーション

プロバイダホームページスペースにはFTPアプリケーションによるアップロードを行う

定番の「FileZilla」や「FFFTP」あたりを使っていれば間違いない

コメント機能

プロバイダサーバサイドスクリプト許可していない限りコメント機能実装は難しい

しかし、需要があるところには供給もあり「DISQUS」というコメント機能が使えないWebページにコメント機能実装させるWebサービスがある

TwitterFacebookGoogle+などのSNSアカウントがあれば書き込むことができる

静的サイトジェネレータ名にDISQUSと加えてググればたいてい情報が出てくる

以上、モダンテキストサイト構築情報として共有する

ちなみにWindowsではWSL環境Ubuntu上にHugoなどを構築すると楽

CLIが苦手な人は従来通りホームページビルダーやDreamweaverを使えば良いと思うが、CLIの利点はGitなどバージョン管理システム管理やすく、今後レンタルWebサーバへ移行しても、容易にそのままホームページを移行できるというメリットがある

WordPressなどのCMSには良い部分が多くあると思うし、顧客が追加要望ばかりしてアホすぎるという意見もわかるし、メシの種だからあんまり触れてくれるなというのもわかる

しかし、顧客が本当に求めているものを探す手立てとする情報提供するくらい俺は問題ないと思っている

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