王振

世界上的選擇很多，每條路都有每條路的曲折及精彩，就如同『二元化思維如何影響著我們的生活?』文章中提到，世界不是黑與白而是多面向的，我們應去練習察覺隱藏在冰山下的事實，這個社會就像一個金字塔，而大夥們就像螞蟻一樣不停的爭相往上爬，身邊的彼此一方面互相協助，同時也互相競爭。 你是否曾感覺，越長大越發現新結交的關係中幾乎是先從彼此的目標或是共同利益開始才能逐漸深入，那次因為隨著成長，大家的見識越來越廣，篩選人、事、物的能力也越來越強，你的思維和行動會決定你往後路途中遇到的人的高度以及彩度，可千萬別小瞧自己的每一小步。大家或許常聽到，『選擇比努力重要』，也應該聽過，『努力不一定會成功，但成功的人都很努力』，但我認為絕大多數的我們並沒有真的很深刻的去了解這句話的涵義

今天想和大家聊聊在軟體開發的資安中，注入攻擊一直是榜上常見的攻擊手段，在開發中若能夠提前擁有注入攻擊的觀念，在設計上可以更好的預防這類型網頁常見的注入攻擊，本篇文章會簡介什麼是網站資安上常見的注入攻擊，並且應該要如何去防範這類型造成的風險。

2023.10月底，打開X和各大加密貨幣相關新聞網站，發現大家分享貝萊德比特幣現貨ETF IBTC 已經被列在DDTC的網站上的消息，而過去一年內態度強硬的SEC(Securities and Exchange Commission)，先後在Ripple、XRP、GreyScale期貨轉現貨的法律訴訟裡敗訴，他們的態度不再像剛開始那樣強硬，加上貝萊德(Black Rock, market cap: $90.6B)、范達(VanEck, market cap: $76.4B) 富達(Fiedity, market cap: $10.2B)、方舟(Ark Invest, market cap: $80.29M)等資產管理巨擘先後提交的現貨比特幣ETF

軟體開發中，資料結構就像是地基一樣，地基打得越穩，對我們再程式開發中絕對是百益而無害！(講講的🤣，其實是因為面試很常問，不得不學呀！） 本文會介紹普遍中計算機科學裡的資料結構有哪些😁

一直以來，我都很想要找個機會來談談活在數位時代的我們是如何一步一步被科技改變自己的行為，科技一直都是人類發展的基石，無論是軍事科技、金融科技、民生科技等等，所有的發展都仰賴科技的進步，幸運也很不幸地，無論你是嚮往活在資本或是共產社會的體系，你都離不開所謂的階層，放眼全世界的國家，你可以用經濟實力、科技實力加上軍事實力來分等級

Context Manager，又稱作上下文管理器，是Python裡的概念，主要用於管理資源的分配和釋放，使用Context Manager可以確保資源在結束使用後會被正確的清除乾淨，避免資源浪費。而Context Manager通常會和with 或 async with語法一起使用，也方便我們閱讀這段程式碼背後是以什麼樣的形式處理。

石油就如同黑色黃金，講到石油就不得不先提到中東各產油國，他們完美示範了何為『真．富得流油』，中東產油各國的原油儲量大約為委內瑞拉(17.8%)、沙特阿拉伯(17.2%)、伊朗(9.1%)、伊拉克(8.4%)、科威特(5.9%)、阿聯酋(5.6%)等都富含大量的原油，其他還有俄羅斯(6.2%)和美州的美國(4%)、加拿大(9.7%)，亞洲的中國(1.4%)，非洲的利比亞(2.8%)等，但是要注意的是，石油儲量不代表產量，而石油產量與開產速度與開採難度有關，天然資源的產地自古以來就是兵家必爭之地，在全球化經貿體系下，石油自然扮演著非常重要的角色，本文就來淺談石油對世界的影響！

AA(Account Abstraction Wallet)錢包aka抽象帳戶的目的是要讓使用者能夠省略背後繁雜的交易機制，把錢包本身弄的跟現今web2的交易模式一樣便利，日常的信用卡、簽帳卡消費、line pay、街口支付、Apple pay等等都是一鍵刷/按一按交易就成立了，消費者們完全不需要知道背後怎麼執行的，而我們都知道在加密貨幣的世界裡你必須要自己持有錢包，必須要保管私鑰(Private key)以及Seed Phrase ...

身為都市大海中的一隻小鯉魚，瞭解負債、資產以及複利可以說是理財的第一課，要明白金錢只是幫助我們達到目的的工具，不需要去害怕談論金錢，很多人很有趣，他們寧願花時間去排隊拿折扣，但是在跟老闆談工資時卻不敢去爭取每個月多2000塊，他們願意買彩券來賭一個極低期望值的獎勵，也不願意好好花時間來培養財商，錢不管怎麼來的都是相同的計量單位，當然我也明白要擺脫舒適圈的確不容易，但習慣是可以一步一步培養的，特別是在25-40歲這段期間，你所累積的價值觀、理財觀以及選擇會造就你將來的人生高度，不可不重視！

常見的微服務架構(Microservice)中，會將各服務拆分到各個容器(container)，但也導致一些問題。 1. 每一次為了要完成使用者提出的需求可能都會一次打出數個到數十個請求到各個微服務容器去，這對客戶來說非常不友善 2. 另一個問題是客戶使用的Protocol不一定相同(比如REST、AMQP)，每個微服務都必須要先驗證是否請求類型支援使得重複性增加 3. 又或是需要重構整個微服務，但由於使用者是直接面向微服務本身的所以導致窒礙難行