發表文章

目前顯示的是 四月, 2017的文章

Linux mint 18.1 安裝 nvidia driver (筆記)

圖片
起因: 由於一個不小心更新到linux kernal 造成重新開機後顯示卡的driver似乎出現了問題,導致我的桌機雙螢幕變成只剩下一個而且還是筆記型電腦螢幕,解析整個跑掉而且還無法調整。並且xserver的GUI跑起來很lag,切換成KDE的桌面環境更直接的跟你說"OpenGL2 無法使用",應該是更新kernal之後原本的顯示卡driver不支援所造成。

賭賭看更新Driver: 此時也只能賭賭看更新顯示卡的driver 之後看看有沒有救了要不然就又要重灌公司的桌機了。於是拿出自己的救援筆電開始上網google linux mint 18.1如何安裝nividia driver了。

有經驗的前輩都會跟你說:『千萬不要去Nvidia網站下載他們的linux driver因為超級容易安裝失敗!』,也因此很多人乾脆都直接安裝xserver-xorg提供的opensource vga driver 不過因為畢竟不是顯示卡廠商提供的,所以在需要顯示卡效能的地方就整個很low。後來發現原來ubuntu有人專門幫大家包好nvidia的driver放到ppa上面讓大家透過ppa來安裝nvidia的driver避免像NV官方那種跑script然後跑一跑就掛掉的情況,所以就安裝看看了。

由於本人用的是linux mint 18.1 他是採用Ubuntu 16.04的核心所以在terminal 下加入Graphics Driver 的ppa

#sudo add-apt-repository ppa:graphics-drivers/ppa

記得最後按一下Enter加入到ppa裡面去。接著我們update一下。

#sudo apt-get update

更新之後透過網站去看最新打包好的driver是那一版。


當下是381因此用他來試試看好了,接著安裝381版的driver

#sudo apt-get install nvidia-381

重開機之後桌機的Desktop GUI就復活了! 好加在不用重灌。
繼續趕工 XD

Ref :
NVIDIA: how to install the latest video card drivers“Graphics Drivers” team

使用Django SimpleUploadedFile 來上傳檔案到資料庫去。~~~(筆記)

起因: 只是想要在python console下簡單測試一個file model是否真的可以上傳檔案,並且依照django setting的media root 設定將檔案上傳到指定位置。

下面是一個django 的database model 的部份內容:
# The FW path and filename def generate_fw_path(instance, filename): return "uploaded_files/{0}".format(filename) class Files(models.Model): file=models.FileField(upload_to=generate_file_path) .......... 其實就只是一個用來放上傳檔案的Database 欄位。

然後該makemigrations 、 migrate 建立database 之後在python的console下測試上傳檔案(ps 我用ipython取代原本弱弱的python 原生console mode。 用pip install ipython就可以使用了)。

清明節的阿里山櫻花季。

圖片
四天的連續假日,發了神經騎著我的Tigra 從台北一路殺回嘉義。剛好遇上阿里山的櫻花季想當然而就在回嘉義的隔天一個人又殺上去阿里山看櫻花。


一趟路嘉義阿里山來回大概要快5個小時,加上阿里山經常在午後起濃霧因此預計能夠在中午前到達阿里山國家公園,然後又考慮櫻花季可能會有不少人也上去看櫻花想說希望能夠早一點出發,不過依舊睡到8點半才起床 > <



說真的個人覺得阿里山公路比蘇花公路還難騎,因為彎道又多而且還不少那種要轉180度加上公車在跑很容易被公車擋在後頭,而且能夠讓你超車的直線路段又超級少反而還比蘇花公路還不好騎。

Django model 遇到datetime 物件比對問題。

圖片
系統: python 2.7.12
Django  1.8.17
OS: linux mint 18.1 Serena
起始: 一開始因為有個model裡面有個欄位是放expire time,用來辨別這個東西是否過期。所以很直覺的就會用datetime來做比對。例如: from clover.models import food import datetime apple = food.objects.get(name='apple') print(datetime.datetime.now() > apple.expire_time)
這邊只是很單純比較apple 是否過期,也就是說當現在的日期大於 apple的過期日~就會印出True, 否就印出False !在命令列去執行時會出現錯誤如下:


出現 TypeError:can't compare offset-naive and offset-aware datetimes  錯誤!
於是乎開始去了解這是什麼問題。

原因: 後來參考了Django 官方網站與Stackoverfollow才又得知一件之前不知道的事情。
由於Django是採用UTC的時區儲存Database有關datetime的資訊,並且是採用time-zone-aware的datetime objects作為內部使用,而且透過轉換這些物件應用在templates與form表單的當前使用者。

再來是關於 offset-naiveoffset-aware 的意義。依照Django 官方的說明是指:
如果這個datetime object擁有tzinfo的屬性並且可以儲存 time zone的資訊就稱作aware
反之naive

這時候我們可使用Django 內建的is_aware() 與is_naive()做測試。

from django.utils import timezone import datetime timezone.is_aware(datetime.datetime.now()) <= False 從這邊可以發現透過系統提供的datetime本身不是aware,所以Django會建議你安裝pytz來做轉換。

解決方式: 簡單的作法是採用Django內建timezone來使用。
例如:
f…

Django 目前的測試整理

使用django 內建的測試指令,django內建會去memory建立一個DB做測試用。# python manage.pytest    去執行所有test開的頭的測試檔。並在需要建立DB的時候建立一個名為test_django的DB做測試#python manage.py testweb.tests.test_signin      -> 指定測試 web/tests/test_signin.py這個檔案#python manage.pytest--setting=portal.settings.ci   -> 指定測試設定檔,例如我們原本都用mysql在開發,但是測試的時候為了加速測試時間,所以可以在portal/settings/ci.py這個設定檔內改用sqlite做測試用的db。所以測試時加上這個參數就可以讓django測試時建立的DB改用ci.py內寫的sqlite。
使用py.test 這邊我有多裝pytest-django 但是無法直接使用pytest-django,因為不知道為什麼會報錯。所以是用pytest-django的優點然後跑py.test。這邊依舊也是要寫個pytest.ini作為py.test起始的設定檔。
[pytest]
norecursedir =.git
DJANGO_SETTINGS_MODULE = portal.settings.ci

主要是告知py.test不要去掃.git資料夾裡面有沒有測試檔。至於第三行的環境設定檔後來發現如果你的virtualenv環境沒有export Django的環境設定,他才會執行這行否則會以virtualenv的環境設定為主並且在需要DB的時候建立DB,測試完之後就會刪除。要注意環境設定檔 (export DJANGO_SETTINGS_MODULE=xxxxxx) 如果像我是有分local開發跟production不同的settings module在run py.test會依env為主,如果env找不到DJANGO_SETTINGS_MODULE的設定,才會依pytest.ini裡面的設定為主。# py.test  就會跑所有的test開頭測試檔。# py.test web/tests/test_signin.py    -> 只執行 web/tests/test_signi…