- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Replit一年付費用戶
因為想試試看AI程式設計工具，所以在12/1黑色星期五特賣期間辦了會員。
選擇它的原因是我的電腦設備不好，
- 無需在本地安裝編譯器或直譯器，即可在瀏覽器中執行並查看結果。
- 無需擔心環境設定，即可學習程式設計。
- 共同編碼專案。(如果我分享連結，就能一起進行pair programming) -如有需要，歡迎任何人一起參與。
- 快速建立程式碼原型和測試。
- 以互動式方式教授學生編碼。
- 輕量級網頁應用程式或API託管。
以後也要用這個拍影片呢。 https://replit.com/
看看世界。(各種新聞)
經濟
2024-11-29 (五) 早晨例行事項 (韓經) : 韓國利率下調 3.25 -> 3.0% / 收入差距擴大，消費下降 / X-ble Shoulder (可穿戴機器人) / 條件型ETF上漲20% (據說外國人買的)
>> 最終，如果外國人不買，股價就沒有上升的辦法呢。
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
成為優秀開發者應遵守的十個習慣
>> 在建立和維護遠端資訊/叢集平台的過程中，我的感受正是如此，但卻未能真正付諸實踐。我們不應該害怕改變，像這樣將任務細分，就能夠實現。
1. 將提交保持得儘可能的小，小到讓你覺得 "這樣小可以嗎？" 的程度。
因為你永遠不知道什麼時候需要回滾特定的變更。知道六天前發生的錯誤的確切位置，並且能夠在沒有複雜的合併衝突的情況下僅回滾該提交，這會讓人感到安心。我的標準很簡單：可以編譯的程式碼就可以提交。
2. 實踐肯特·貝克的格言："為了想要做的變更，先讓變更更容易（注意：這可能很難），然後再做更容易的變更。"
"為了想要做的變更，先讓變更更容易（注意：這可能很難），然後再做更容易的變更。"
讓超過一半的提交是重構。持續重構指的是找到並應用可在 10 分鐘內完成的改進。這些小的改進讓日後遇到大型需求時，只需簡單的修改就能解決。應該避免大型重構。
3. 所有程式碼都是債務。
未部署的程式碼是債務中的債務。必須確認程式碼是否正常運作，至少不會破壞其他功能。測試會帶來信心，生產部署會提供驗證。頻繁部署可能會稍微增加託管成本，但能夠確認最後的工作確實取得了進展，這一點非常有價值。敏捷原則之一是 "可運作的軟體是進度的主要衡量標準"。這裡的 "運作" 和 "進度" 具有關鍵意義，因此我做了自己的定義。"運作" 指的是可部署的程度，如果程式碼有助於某個功能，那就是 "進度"。
4. 自問一下，你是否正在測試框架的功能。如果是的，請不要這麼做。
框架已經由比你專業得多的人員測試過，你應該相信 useState() 鉤子會按預期工作。保持元件小巧，框架就能處理大部分核心工作，因此不需要太多測試。元件越大，複雜性越高，需要編寫的測試就越多。
5. 如果特定函式與任何地方都不相符，請建立新的模組（或類別或元件），然後再尋找合適的位置。
與其勉強將其塞入感覺不相符的地方，不如建立新的獨立結構。即使是最糟糕的情況，它也能夠作為獨立模組存在。
6. 如果你不知道 API 應該是什麼樣子，請先寫測試。
這會讓你從 "客戶"（在本例中是你自己）的角度思考。如果你先寫程式碼，然後再寫測試，你可能找不到這些情況。不必過於教條地遵循 TDD，可以用更大的單位工作（例如：在測試通過之前寫幾行程式碼）。失敗狀態的程式碼量不必總是很少。如果你知道自己在做什麼，請確保原則不會降低生產力。
7. 複製貼上一次是可以的。
不要進行第二次重複（也就是第三次複製）。此時，你應該有足夠的案例來建立良好的抽象。由於相同功能的實作彼此不同的風險太大，因此需要整合。與其多次實作相似的功能，不如使用稍微笨拙的參數化。如果這種情況再次發生，改進參數比整合四個不同的實作更容易。
8. 設計注定會過時。
重構可以減緩其速度，但最終你必須改變其運作方式。當你必須放棄過去珍視和引以為傲的事物時，不要太難過。你當時已經盡力了，而且不必為沒有做到完美而自責。軟體開發的大部分工作都是改變軟體。接受這一點，然後繼續前進。沒有完美的設計，改變是軟體開發的核心。你能夠多熟練地進行改變，決定了你作為開發者的能力。
9. 技術債務可以分為三類：
1) 干擾目前工作的東西，2) 將干擾未來工作的東西，3) 可能會干擾未來工作的東西。所有其他分類都是這三類的子集。盡量減少 #1，專注於 #2。別理 #3。
10. 可測試性與良好的設計密切相關。
難以測試表示需要更改設計。有時，該設計可能是測試設計。例如，如果很難模擬 em.getRepository(User).findOneOrFail({id})，最好將該呼叫分離成一個可模擬的函式，或者編寫一個測試工具程式，讓你可以輕鬆模擬實體管理器方法。測試沒寫的原因不是因為不想寫測試，而是因為難以測試。
评论0