在建立網站時, 常常需要一個環境可供測試與驗證, 但又不需要像是一個虛擬機這麼大的服務, 有個佛心的廠商, 提供了免費的代管, 可以透過以下推薦碼來取得:
https://ccp.cloudaccess.net/aff.php?aff=5493
這個網路服務提供商提供了免費代管 wordpress 與 joomla 兩大應用服務, 可以線上直接啟用, 免費的版本也可以有多個網站, 但每 30天需要 renew 一次, 若 30天內沒有 renew, 網站就會被關閉.
這是一個用來做為測試與驗證, 甚至短期服務的一個網站提供商, 免費版的後端就可以有 ftp 與 phpmyadmin 管理資料庫, 十分方便, 來看看後端吧:
這個是 ftp:
備份管理:
資料庫管理(phpMyAdmin):
真的是太方便, 太佛心了, 不過網址只能使用 xxx.cloudccess.host , 若要自訂, 也是需要付費的, 付費方案比較, 請參考:
https://www.cloudaccess.net#pricing
記得申請帳號使用以下推薦連結:
相片副檔名
之前在實作上傳圖檔活動時, 使用副檔名為 .jpg 的約束條件, 但發現在 iOS 設備選擇相片後, 無法成功通過驗證, 經實測後, 發現存在 iOS 相簿裡的 jpg 相片都是以 .jpeg 為副檔名, 所以在上傳時, 會無法通過副檔名驗證.
即使將 .jpg 圖檔存下在 iOS 設備裡的相簿, 也會被轉換檔名為 .jpeg 的副檔名, 這個狀況需要在實作上傳圖檔時需要特別留意.
相片方向
使用 iOS 設備拍照時, 存放檔案方式, 會以橫放方式存放 ( w > h ), 但直拍時, 一樣使用橫放方式存檔, 但是會有個 orientation 為轉向, 方向為 right-top (6), 也就會變成直向, 詳情可參考這裡的圖片與說明:
https://www.impulseadventure.com/photo/exif-orientation.html
所以若是 6 就可以利用順時鐘轉 90度回來正確的檢視.
相片方向在網頁上
另外有趣的現象是, 該圖在 PC / Mac 桌機, Android 手機時, 直接放在 web 連接, 會是正常的轉向出來, 但放在 html 裡使用 img src 的方式, 則會無法轉向, 不過 iOS 設備在 html img src 引用時, 仍能正常轉向.
測試與重製
使用一張 iOS 拍照, 但縮小保留 EXIF 轉向資訊圖片供測試參考:
https://codepen.io/timhuang/full/ZmmQjy/
在 iOS 設備上可以正常轉向, 但其他不然, 但又是直接連結也是可以成功轉向的, 第三個部分則是使用了 images.weserv.nl 服務, 它會將原來的圖檔轉正, 並將轉向改為正向方向, 也就能解決這個問題. 這個服務的介紹可以參考: https://diary.tw/archives/221
讀到這篇: https://gfamily.cwgv.com.tw/content/index/12938
雖然之前美國總統歐巴馬也做了 – https://www.ithome.com.tw/news/92882
也鼓勵了- https://www.bnext.com.tw/article/38622/BN-2016-02-01-070820-81
但學寫程式這件事並不是重點.
重點在於學會邏輯, 推理, 演繹, 科學, 至於寫程式, 也不過在於組合這些東西.
之前常在說, 未來是不需要人類來寫程式的, 寫程式的人, 是在寫”寫程式的機器人”的程式, 所以除非你對程式有高度熱忱, 有高度喜好, 否則這不是件好工作或好技術, 反而, 學會程式能做些什麼, 能幫助什麼, 能解決什麼才是重要的.
回到本質, 科學, 人文, 持續學習, 這才是重點, 寫程式是其中一種技能, 一種輔助, 未來你只需要指揮電腦, 只需要了解操作電腦, 寫程式, 其實沒那麼重要.
不過若你想學, 還是歡迎, 因為只要從中能讓你學得那怕是一點點的邏輯, 一點點的推理, 都是很棒的, 更能讓你知道, 寫程式不是萬能, 不是什麼都做得到, 我們需要的是累積經驗與傳承, 人類的學習與探索的精神與態度才是最重要的.
繼續閱讀:
微軟技術捷運-創新科技的線上課程
https://www.microsoft.com/taiwan/mstechmrt/
這裡提供了許多線上影音課程, 可供技術人員學習研究, 方便又快速的學速方式, 讓技術學習更容易. 共有: 人工智慧、物聯網、IT系統架構、DevOps、企業生產力等五條學習軌道, 大家可以挑選自己感興趣的軌道來學習.
我們在寫 Menu 時, 會利用 li tag 來進行, 如下:
<ul> <li>HOME</li> <li>NEWS</li> <li>CATEGORY</li> <li>CONTACT</li> <li>ABOUT US</li> </ul>
一般來說, 會需要將原來的 li 前面的符號點去除, 會使用 CSS:
ul {
list-style-type: none;
}
然後在 li 本身的原來預設 display: block 要改為 inline:
li{
display: inline;
}
接下來是需要在每個 menu 中間放個分隔符號如: |
li + li:before
{
content: '| ';
}
達成效果: https://codepen.io/timhuang/pen/vzaYXo
有趣的是最後這個 li + li:before 語法, 可以不用到排列子元素的方式, 而是用緊鄰的方式來選擇, 如此一來, 第一個 li 就不會滿足這個條件, 只有第二個到最後一個可以滿足, 而達成在每個 menu 間下分隔符號.
其他解法尚有:
之前使用 google colab 的 python 線上環境後, 現在 M$ Azure 也有對應的環境了:
一樣免費線上使用, 把之前的 factorial 程式放上去做個小範例:
https://notebooks.azure.com/timhuang/libraries/myprojects
請自行執行 factorial.ipynb 即可. 這樣在 Google 與 Azure 上都有方便好用的 notebooks 可用了.
話說 Google Chrome 有個底線在有下區間英文字, 如 p, g, q 等會出現斷裂的狀況, 經查原因為 Google Chrome 於 64 版本起, 開始支援 text-decoration-skip-ink 為 auto 了, 所以發生這個狀況:
如何解決呢, 當然就是將其屬性設定為 none 即可. 如下:
.noskipink{
text-decoration-skip-ink: none;
}
由於預設連結也會有用到底線, 所以一勞永逸的方式就是把 a 元素的該屬性設定起來即可. 這個在 firefox 與 IE 沒有問題.
看起來也不是 chrome 問題. 而是在 css 4 版本起有這個 tag (draft), 而 chrome 64 起支援了, 所以就發生破裂的狀況, 而其他瀏覽器不支援所以不會有這個破裂的現象.
範例與測試請連結: https://codepen.io/timhuang/pen/XYKaNO
參考資料:
今天在實作 data-attributes 時, 發現僅能用小寫存取. 一般我們對於較長的變數名, 會使用駝峰命名法 (camel naming), 不過在 data-attributes 會發生問題.
因為在 data-attributes 這樣的結構下, 都是以小寫方式來進行存取, 所以即使是使用 data-numberOfData 也會使用 data(“numberofdata”) 的方式來存取, 否則會 undefined.
若希望能用駝峰式名稱來存取, 則需要使用 data-number-of-data 的方式來寫 tag, 就可以使用 data(“numberOfData”) 來存取.
可以參考以下程式:
<a id="linka" data-string="a">link a</a><br>
<a id="linkb" data-stringOfData="b">link b</a><br>
<a id="linkc" data-string-of-data="c">link c</a><br>
// jQuery javascript
document.write("#linka.data(\"string\") = " + $("#linka").data("string")+ "<br>");
document.write("#linkb.data(\"stringOfData\") = " +$("#linkb").data("stringOfData")+ "<br>");
document.write("#linkb.data(\"stringofdata\") = " +$("#linkb").data("stringofdata")+ "<br>");
document.write("#linkc.data(\"stringOfData\") = " +$("#linkc").data("stringOfData")+ "<br>");
上面的執行結果, 第二組會是 undefined, 其他可以正常輸出 data-attributes 內容.
可以參考 codepen 上的執行結果:
https://codepen.io/timhuang/pen/ZRYzOR
一般在表單送出後, 若非本頁更新的方式, 而是走 AJAX 方式送出時, 需要一定處理時間等待 server 回應的作業, 若是使用者未能完成執行完成, 而進行更換頁面時, 造成之前表單送出異常或失敗, 此時可以考慮使用這個功能來防止使用者不小心重載(reload), 或是離開頁面. 另一個狀況則是目前表單還未送出時, 但已修改, 如部落格文章編輯時, 已進行修改但未送出, 也是可以使用這個功能來達成.
這個功能是對 window 綁定一個 beforeunload 的事件(其實也就是 addEventListener 或是使用 onbeforeunload 皆可), 不過實測因各家瀏覽器工作方式不同, 無法成功設定自定訊息, 只能由瀏覽器的預設訊息提醒, 在一般狀況使用下, 沒太大問題. 使用方式如下:
// 有引用 jQuery 的狀況下
// 註冊
$(window).bind('beforeunload',function(){
return '您確定離開此頁面嗎？請記得存檔！';
});
// 解除
$(window).unbind('beforeunload');
其中的訊息請忽略, 因為實際上會出現的訊息與各瀏覽器有關, 但特別要注意的地方是若是已知可以 reload 或送出成功後, 記得要取消, 才不會因為真的成功後, 要重導頁面時, 又出現需要使用者確認的訊息.
以下為在 codepen 的範例:
https://codepen.io/timhuang/pen/YLgvXJ
測試方式為, 先點 bind 後, 成功綁定事件, 再點下方 codepen 連結離開, 此時會出現確認訊息, 來防止或確認離開, unbind 則是在 bind 之後, 再 unbind 就不會觸發這個 beforeunload 確認.
繼續閱讀:
階乘(Factorial)是從1 x 2 x 3 x …. x n 記作 n!
其中比較特別的是 0! = 1, 原因為 n! = n x (n-1)! 而 1! = 1 = 1 x 0! 所以定義了 0! = 1
不過今天不是要談這個, 而是要用程式計算 n! 的確實值, 用什麼程式語言可以做到呢? Python3
來看看程式吧:
p = 1 for i in range(1,100000): p *= i print(p) print(len(str(p)))
根據 Python 算出來的結果為 28242294079603478742934…….
共有 456569 位數.
厲害的地方是 Python 3 沒有位數的限制, 可以算出這麼多位, 真的太強了呢. 有興趣的朋友可以線上執行:
https://colab.research.google.com/drive/1ayDGtmAiWYRzhPXOUc_uefvQD8RXvIp_
以上為使用 Google colaboratory 服務執行. 記得要使用 Python 3 就沒有位數上限(有的話是在記憶體上限, Python 2則有位數的上限)
[2018/5/18 12:12]
補充一下, 使用 python 內建數學函數庫的方式:
import math p = math.factorial(99999) print(p) print(len(str(p))) type(p)
線上執行:
https://colab.research.google.com/drive/1_n9r6gq-p-7qoT6wjeiTVsnntwktaj8q
當然, 結果還是一樣的.