面倒な事をシステムでなんとかする弊社では勤怠システムがWEBシステムになっているのですが、忘れることがあったのでえいやーでなんとかしてみました。https://${API_HOST}/dashboard/${_TYPE}/exit適当なファイル名eiya-de-kintai.shとして保存し、実行権限をつけておきます。~/eiya-de-kintai.sh実行するには以下のようにします。・出勤もしくは退勤(-tで指定)のエンドポイントへログイン状態のcookieを使いtokenをPOSTログイン判定してないとかcookieが残骸として残る等かなり手を抜いているがひとまず気にしない。徐々に手を加えていく予定。Macの起動と終了で処理を走らせるには、「Macの起動=アプリケーションの起動」、「終了=アプリケーションの終了」とみなすことにし、作成したシェルスクリプトを呼び出すApplescriptを作成しました。quitこれをファイルフォーマット:アプリケーションオプション:ハンドラの実行後に終了しない。出来上がったアプリケーションをMacのログイン時に実行されるようにします。「システム環境設定」にある「ユーザとグループ」を開き「ログイン項目」へ作成したアプリケーションの登録を行います。以上でとりあえずのものが出来上がりました。Macを起動し、ログインすると自動で出勤処理が行われます。Macの終了時には自動で退勤処理が行われ、何も意識しなくても勤怠処理が行われるようになりました。エラーさえなければ・・・アカウント情報を平文で書いているとかApplescript使うならシェルいらないのでは?とかエラー処理されていないとか、実用するにはまだまだまだまだ改善すべき箇所が多く残っていますが、ひとまず目標は達成しました。8.1から追加された機能にRead-Onlyモードがあります。SolrCloudでの運用時に利用できるモードです。リファレンスマニュアルの該当部分を翻訳してみました。readOnly属性をtrueにセットするとコレクションはRead-Onlyモードに移行します。このモードではインデックスの更新リクエストは拒否されます。他のコレクションレベルのアクション(コレクションの追加/削除、レプリカの移動)はこのモードにおいても有効です。(デフォルトの)read-writeモードからread-onlyモードへは以下の手順で移行されます。FORBIDDENエラーで拒否される(継続中の長期実行リクエストは中止される)・実行中の更新が強制的にコミットされる(注意)大きなセグメントがバックグラウンドでマージされている最中であれば、この強制コミットは長時間に及ぶかもしれません。・コレクションのRELOADアクションが実行されるreadOnly属性が削除されるかfalseに設定されるかすると、更新リクエストが有効になりコレクションがリロードされます。https://lucene.apache.org/solr/guide/8_2/collection-management.html#readonlymode簡単な動作確認をしてみました。parameterテスト用のコレクション(test_readonly)を作成し、MODIFYCOLLECTIONアクションでreadOnlyをtrueに設定してからドキュメントをポストするとリファレンスの説明通り403エラーになりました。}}当然インデックスは空っぽのままです。0:00:01.420次にMODIFYCOLLECTIONアクションでreadOnlyをfalseに戻してからドキュメントをポストしたところ、今度はエラー無しでアップデートできました。}}クエリの結果からも、正しく更新できたことを確認できます。ReadOnlyモードを使えば内容固定のインデックスを運用中に誤って更新してしまうことを防ぐことができて便利ですが、このモードはSolrCloudでのみ利用可能なので、その点は注意が必要です。LaravelとVue.jsでWebSocketしてみる秋になると「紅葉見に行こうよ」と言いたくなるけど言う相手がいない。気づいたら紅葉シーズン終わっていた。Laravelを触ってみてVue.jsってどんなもんだろうと調査してみる機会がありました。他のメンバーがずっと以前の社内勉強会で発表してくれていた通りものすごく便利なことに気付かされました。長くjQueryに甘えていたのでこの場合はどうするの?がたくさん。今回はWebSocketしてみました。参考サイトhttps://readouble.com/laravel/5.7/ja/broadcasting.htmlhttps://qiita.com/zaburo/items/34289d4573f39113b25aいきなり参考サイトですがこの手順通りに対応すれば動作確認できちゃいます。ありがとうございました。startURLをディレクトリ指定にNginx設定する。$remote_addr;}jsのpathにディレクトリを指定する。});感想ほんとに全然JavaScriptコードを書かずともLaravelでWebSocketを利用できることにシンプルに感動でした。採用すると発表してから11ヵ月、もうすぐ1年になろうとしています。ベータ版も落ち着いたのではないかと思い、インストールから一通り触ってみた感想を書いてみます。ダウンロードができます。ビルドをインストール。起動せよと呼ぶ声あり起動時の画面がこちら。開いた最初の画面メニューはこんな感じです。表示させて並べてみました。いくつかWebページを見て回りましたが、閲覧程度なら現行ブラウザとも遜色なく動作しているように見えます。「既知の問題」を見るとまだいくつかの問題は残っているようですが、随時修正されていくでしょう。ないユーザーエージェントは以下のようになっています。至っていないということなのか、このまま本採用されるのか。開発者視点だと気になる点ではあります。アドオンが利用できるようになるとのことなので試してみました。開くと画面上部にメッセージが。追加」のボタンが現れます。押してみると何事もなく拡張機能に追加されました。小さなプレイヤーが表示され動画が再生されています。試した限りでは残念ながら一時停止ボタンが機能しませんでした。似た何か」であり、それ以外の感想は特に出てきませんでした。し過ぎていて、どちらを使っているのか分からなくなります。そこからの独自機能の実装という方針なのだと思います。等、気になる名称の機能が試験段階として無効化されていることが分かります。ユーザーに受け入れられるのかどうか。期待しているポイントです。問題ないということになれば、多くのWeb開発者の救済への大きな一歩となるかもしれません。似た何かで終わる可能性もあり...。様におかれましてはどうかうまくやってくださいと強く祈るばかりです。触ってみるにコメントWSL上でSolrが動くかどうか試してみたSolrはJavaで書かれているのでもちろんWindowsでも動くわけですが、ふとWSL上ではどうなのかが気になって試してみました。上でいつもの手順通りSolrを動かしてみます。130)エラー終了してしまいました。VMレベルでのエラーが発生していました。https://bugs.launchpad.net/ubuntu/+source/openjdk-lts#WSLのバグレポートによるとJavaのプロセスで似たようなエラーが出ることはあるようで順次修正はされているものの、今回のエラーと同じものは見つかりませんでした。VMの起動オプションを変更すれば起動するのではないかと考えて、まずはヒープサイズをいろいろ変えてみましたが駄目でした。次にJMX関連のオプションを外してみたところ問題なく起動するようになりました。具体的には起動用のSolrスクリプトを以下のように変更しました。then開発中の動作確認ではWSL側でSolrが動かせた方が都合が良い場合もあるので、謎のエラーを回避する方法を見つけることができて良かったです。usコンサルティング・Webサービス開発を得意とします。コミュニケーションのあたらしいカタチを創造します。