一月 21, 2014
» SOLVCON Outlook, 2014

SOLVCON Outlook, 2014

I like to code and engineer for continuum-based first-principle simulations. Although numerical simulations inherently have limitation, to use computers to get to the details and insights is fascinating, especially when the problems are otherwise difficult to be studied. A table, some pencils, a laptop, and data centers are all we need. Oh, and we don’t need to physically touch a data center (or we aren’t allowed to do so :) It’s amazing to be able to see so much with so little.

But it doesn’t mean the simulations are simple, although the building blocks are really just mathematical formulations and computer code. Remember devils are in the details. Correct and accountable simulation results are as challenging as physical experiments, but call for a different skill set. We have to realize that doing the simulations means making special computer software, of which the prerequisite is the “domain knowledge” that takes years of study.

The point is that we are making software. For scientific research, there is an impression that the efforts on software should be minimized. Many researchers don’t have long-term thinking about their code. That causes problems. A computational scientist can be sure about nothing other than the formations and the code. If we don’t program with discipline, our simulations won’t have desired credibility. From empirical equations, semi-analytical simulations, one-dimensional simulations to three-dimensional, massively-parallelized simulations, the ever-increasing computing power drove the code to be more and more complex, and we simply need to work like professional programmers to properly organize our calculations.

Better Engineering for Science

More engineering practices should be brought into the picture. We need to construct the simulation software with discipline, but engineering software is pretty different to other engineering. In software, there’s no “real thing” that can be verified by the Mother Nature. Many of us may not be familiar with the skills and tools to be employed.

The goal of SOLVCON is to let a researcher focus on developing research code that uses the CESE method. From the engineering perspective, collaboration is good and it’s not reasonable to ask a single person to understand every detail from the choice of design patterns to the development of constitutive models. Ultimately, we hope everyone who’s interested in SOLVCON’s applicable areas can find a comfortable place to contribute.

But it is unclear that how many and what roles there should be for a good team. How people should collaborate? How should the responsibility from different roles to overlap? For a usual research team in a university, we don’t need to answer these questions, because the team is more or less constrained by how academia is working. SOLVCON is an open-source project. It enjoys a high degree of freedom and the only significant constraint is resources. We can make different try.

Scope is still needed for a project. The basis of SOLVCON is (i) unstructured meshes (Voronoi-based) of mixed elements, (ii) the CESE method, and (iii) hybrid implementation of Python and C. SOLVCON is open-sourced with a permissive license so close-source applications are OK. On that basis we want to learn how to do good computational science with good software practices.

Documenting

The first thing to consider is communication, which is important for both science and software. Open and critical discussions make ideas to grow into solutions. In the software development communities many systems and services have been developed to facilitate communication in development teams. Documenting is the most prominent system, for all we have are just code and formulations.

Formulations are what common software projects don’t have. There are some solutions available, and SOLVCON uses Sphinx as the documenting system. In this way, the formulations and the simulations will be integrated into the software’s document. In-progress demonstration can be found at http://www.solvcon.net/en/latest/app_bulk.html and http://www.solvcon.net/en/latest/app_linear.html.

One challenge with the traditional research papers is that the they can’t carry code. For a medium-sized project of more than a thousand lines of code, the separation between code and passages makes either part difficult to be maintained. The SOLVCON documenting system wants to improve this. By using “readthedocs” and “BitBucket”, producing the cross-referenced document online is just several clicks away.

Version Control and Building

Although everything about numerical simulations is in computers, we still can say that we have one tangible asset: source code. The source code should be properly managed and can be made to the center of all communication. In software development it is called version control, and there are many version control systems (VCS) and services at our disposal. SOLVCON uses Mercurial (hg) with the BitBucket hosting service. BitBucket also provides a nice issue tracker and can hook into other online services.

Source code needs to be built before running. Building the binary code from source code involves compiling, linking, and organizing the intermediates at proper places. It’s much more complex than just compiling so that we need a build system. SOLVCON uses SCons to build its binary parts. Standard Python distutil is used after SCons for making source package.

In addition to building, SOLVCON provides scripts in “ground/” and “soil/” directories to build third-party software packages, if they are not otherwise available. The dependency management is especially important when running SOLVCON on a supercomputer site, for usually the pre-installed software packages are not sufficient to run SOLVCON.

Testing

Testing is something can’t be taken away from the development cycle. It is different from the result verification for an under-development simulation, but about repeatedly confirming the already verified (or partially verified) results are still valid.

In SOLVCON there are three levels of testing: the unit testing, functional testing, and solution testing. The unit testing is using the standard Python unit test framework and doctest. The functional testing is arranged for interoperation of different modules in the software system. Solution testing is responsible for making sure the calculation results remain the same after when changing the code. The solution tests are collected in the “examples/” directory, and scripts of running these solution tests or examples are provided.

It is important to separate the testing into levels. We should constantly run tests to check that we don’t break code, because if we do, it takes more time to fix errors in the future than to avoid errors during development. Usually, the more involved tests need more resources and more complex setup. For example, all unit tests in SOLVCON can be run with a single “nosetests” command, and they finish in 10 seconds on my MacBook Air. In contrast, a solution test for a solver in SOLVCON takes 10 minutes on a 8-core server. We can use unit tests to quickly detect errors, and the expensive solution tests only need to be invoked at a late phase of development.

A continuous integration (CI) system (Jenkins) is set up at http://ci.solvcon.net/ to carry out all the tests and code building with every commit in the source code repository. If a developer forgets to run the tests, the CI system will still run them anyway. Whenever it’s possible, we should set up automation to do repeating tasks and free up developers’ or researchers’ time for something more valuable.

Scheduling for Collaboration

To some extent, developing code is like developing formulations. They both consumes large chucks of time and are usually a standalone activity that requires one to get into the “flow” for efficient and quality work. That is, we can’t be disturbed in the middle of the work flow or we will lose a lot of productivity.

If we centralize the work to software development, or, in another word, do computational research like we are developing software, then collaboration techniques for software can come to help the research. Because research teams are usually small (tens of people or less), we should adopt established agile methodologies like Scrum, Kanban, eXtreme Programming (XP), etc. These methodologies are not addressing how to manage the “domain knowledge”, which is our focus of computational science. We need to adjust them to balance the software and non-software parts.

Conclusions

This isn’t the complete description about what SOLVCON wants to achieve, but provides an overview for its possible contribution outside its basis. The fundamental infrastructure mentioned above is already there. The project should be expanded to find out how far it can go. For now, the use of the CESE method is a limiting condition for its applications, but also an opportunity to bring new things into unexplored application areas. Preliminary applications developed for supersonic flows, waves in solids, and acoustics can be used as working models.

I hope to know more people who are interested in this model of developing PDE solvers or the CESE method, and try a fun approach of doing computational research together.

十二月 18, 2013
» Recall Internal Laminar Flows

Recall Internal Laminar Flows

My memory about the classic flow problems faded in the past several years. The notes here are my redemption.

Consider the steady-state, fully-developed, incompressible, viscous laminar flow between two infinite long parallel plates. x, y, z are the axes of the Cartesian coordinate system and all flow properties remain the same in the z direction. The flow direction is toward +x. Let u, v be the velocity in the x, y directions, respectively, p the pressure, and \tau_{\xi\eta} the stress. Let the lower plate be at y = 0 and the upper plate be at y = a, where a is a given constant.

Consider the x component of the momentum equation on a infinitesimal square control volume that’s \dif x wide and \dif y high:

& \left[p - \left(p + \dpd{p}{x}\right)\right]\dif y
- \left[\tau_{yx} - \left(\tau_{yx} + \dpd{\tau_{yx}}{y}\dif y\right)\right]
  \dif x = 0 \\
\Rightarrow & \dpd{\tau_{yx}}{y} = \dpd{p}{x}

Assume Newtonian fluid:

\tau_{yx} = \mu\left(\dpd{u}{y} + \dpd{v}{x}\right)

where \mu is the dynamic viscosity coefficient. Because the flow is fully developed, the vertical velocity v is void and thus \tpd{v}{x} = 0:

\tau_{yx} = \mu\dpd{u}{y}

Then we obtain the following equation for u:

\mu\dpd[2]{u}{y} = \dpd{p}{x}

Let \tpd{p}{x} be constant (this can be justified) and apply the conditions of u(0) = u(a) = 0:

u(y) = \frac{1}{2\mu}\dpd{p}{x} y \left(y-a\right)
     = - \frac{a^2}{8\mu}\dpd{p}{x}
       + \frac{1}{2\mu}\dpd{p}{x} \left(y - \frac{a}{2}\right)^2

For \tpd{p}{x} < 0< 0" />, u \ge 0 and the peak velocity is u(y = a/2) = -(a^2/8\mu)\tpd{p}{x}.

六月 6, 2013
» After PyCon Taiwan 2013

After PyCon Taiwan 2013

../../../../_images/pycontw2013_bag.jpg

More and bigger pictures are in the gallery.

This year the conference was great. Totally beyond my imagination. This single sentence hit me when I walked into the confenrence hall: “Oh yes, THIS is what I always want to see.”

../../../../_images/conference_hall.jpg

A vibrant community of gentle people enthusiastic to Python. The second PyCon Taiwan worked just like what described by Peter, one of our organizers: “The annual convention in Taiwan for the Python community, by the Python community, and of the Python community”. I hereby thank all the participants to the conference. You made it great!

../../../../_images/everyone.jpg

Everything in the conference was great, but perhaps the most exciting thing is the technical program. This year we ended up with 33 talks selected from 50 proposals (plus 4 keynotes, 1 off-conference tutorial, and 1 in-conference workshop). It’s a pity that we had to reject some very good ones, because we were too conservative when planning the conference venue. Three rooms were just too few (yes, if you were rejected this year, don’t be sad. You are good. The 30% rejecting rate is totally my fault). Our invited speakers made a lot of contribution to the technical program: David Beazley, Jan Decaluwe, Allen Downey, and David Cramer. There are also people from overseas came to join us, even from the other edge of this continent. In the conference, I can feel that Python and its development are at the center. I like it so much.

../../../../_images/agenda.jpg

One really cool thing we tried this time was the night market. In the agenda it was named “Reception” or “BoF (Bazaar of Folks)”, but really what we meant was “night market (夜市)”. Yes, the night markets, a.k.a. night bazaars or street markets that operate at night, you are told the must-see in Taiwan. We brought it from the street to the conference for Python.

../../../../_images/reception.jpg

The success of PyConTW night market surprised everyone of us, because it was worked out in only two weeks by only two volunteers: bug and strong (and they were also having other tasks at the same time). For late start, when Strong spoke to me at the first day: “Hey Yung-Yu, could you please make an advertisement at the opening that there are still 3 booths left for sign-up?” my reaction was: “Are you kidding me that you have filled all the booths with only 3 left? Are you sure you were not saying we have 3 booths signed up?” (Of course I was just thinking those words without speaking out :) It turned out that almost all the tables we prepared were occupied, and PyLadies at Taiwan kicked off at that night. And there were many cool stuff exhibited at that night. It’s simply great!

../../../../_images/pyladies.jpg

Night markets are one honking great idea – let’s do more of those!

In the second year of PyCon Taiwan, we reached 400 attendees. Compared to the 260 attendees last year, the number increased 50%. Last year we received 20 proposals, and compared to the 50 we got this year, the technical proposals grew 150%. These facts showed the Taiwan Python community is being motivated. In addition to the conference, we’ve also seen metro-area user groups are founded. After we started PyHUG in 2011, Taipei.py was founded in 2012, and Tainan.py will kick off soon. More and more people are getting together and sharing Python. We are building a happy community.

I have a feeling that we’ve reached the critical mass, and the community is moving by itself. At this time, the people who initiated the efforts should fade out from the spotlight, so that more people can come and drive the community with more diversity. After discussion in the last organizing meeting before the conference, the organizing team concluded that WenChang “Tim” Hsu will be the new conference chairperson. There will be a period of transition, but after a couple of months, Tim will lead the team to organize our next PyCon in Taiwan of more fun.

../../../../_images/tim.jpg

We’d like to thank all the attendees and sponsors to the conference. During the organizing process we were reaffirmed that we really are of the same community. I want to give special thanks to the organizing team. You have contributed tremendous efforts to make the conference great. There are many works that are not so “cool” but critically important, like coordinating sponsorship, registration, venue preparation, finance, so on and so forth. None of the staff complained a word when doing some really tedious tasks. Please be reminded, all of the staff paid the tickets, did the work, and missed many great talks. I think the whole Python community in Taiwan should thank for their dedication! (But of course, better scheduling for volunteers’ time is on the top of our to-be-improved list.)

And if you want to give to the community, you are lucky! There will be a lot of things you can do. Send an email to organizers@pycon.tw and tell us what you can do for the community.

If you miss what you’ve just experienced in PyCon Taiwan 2013, don’t hesitate to go to your local Python user group. In Hsinchu you have PyHUG, in Taipei there’s Taipei.py, and visit the Tainan.py page to find out what you can do to help build it. Having fun with Python and the community everyday surely will be better than doing it once a year!

蛇年真是 Python 年,是吧。

五月 12, 2013
» Write Good Code

Write Good Code

Computational scientists use computers to resolve difficult problems, but many of us don’t know how to write good computer programs. This is ironic. It will be good if we can better engineer our code.

Good code is strong in three factors: (i) correctiveness, (ii) performance, and (iii) productivity/maintainability. For scientific applications, correctiveness is the most important one. It’s pointless to produce unreliable results in any discipline. Sometimes erroneous results are even catastrophic, e.g., the Excel error.

It’s not easy to write good code, but there are some basic principles to achieve that:

  1. Make your code look consistent and organized, or in another word, beautiful. Although beautiful things are not always right, ugly code is usually buggy. And inconsistent or unorganized code is definitely difficult to be maintained. Follow a style convention as much as you can.
  2. Always do version control. A useful software project has at least thousands of lines of code and takes months to be completed. The changes need to be tracked or we lose some information in the history. Version control is also critically important for efficient working flows and collaboration.
  3. Write appropriate, accurate, and abundant documents. In the settings of modern research environment, writing papers is usually a central activity of research. Documenting code should be granted the same value as paper-writing. If we publish a paper that doesn’t follow the code, we aren’t doing a quality work. The papers we published should be part of the code documents, as they support each other.
  4. Test as much as possible. Although testing is the core of code quality, itself alone isn’t very helpful. If we don’t code with discipline, it’s difficult to perform tests, and even if we can, the tests aren’t effective. Tests should be alert to regressive errors in code. If possible, it’s good to make tests to be detective to potential flaws.

When I have time I want to write about systems and tools that can help us to follow these principles in the context of computational sciences.

三月 4, 2013
» PyCon Taiwan 需要你的投稿

PyCon Taiwan 2013 call for proposals 延期到 3/11 23:59 截止收件 (http://tw.pycon.org/2013/zh/blog/2012/11/21/call-for-proposals-zh/,英文版為 http://tw.pycon.org/2013/en/blog/2012/11/21/call-for-proposals-en/)。請大家踴躍投稿。真正希望大家能以不顧一切 (?) 的心態,把你與 Python 有關的心得分享出來。

這個開場白有點怪怪的。在理想的狀況下,我是不需要寫這篇文章的。不過現實總和理想有點差距,所以我有責任在此說明情況,希望社群能支持 PyCon Taiwan 今年的努力。

PyCon Taiwan 需要你的投稿

PyCon Taiwan 是一個技術研討會。這不是籌辦者特選的定位,而是基於我們以程式語言為主題這個事實,所自然推演而來的結論。技術研討會,或者直接說技術社群,最重要的是活力十足的技術分享。在研討會中,此表現為豐富而具互動性的技術議程。所以對 PyCon Taiwan 來說,各位 Python 愛好者的投稿,是研討會最重要的主角 (Python 娘 http://weijr-note.blogspot.tw/2013/02/python-debut.html 當然也是很重要的。Patches should go to weijr and are very welcomed)!

每一位使用 Python 的同好,我們都希望看到你的投稿。我們希望看到你站在講台上,和大家分享各種使用 Python 的心得。我想要強調,PyCon Taiwan 是鼓勵「心得的分享」。說起在研討會演講,我們很容易會想說要作出了不起的高段技術,好上台語驚四座。這雖然非常好,但其實 PyCon Taiwan 沒有要強調這種作風的意思。研討會提供的是「讓大家分享的場地」。身為技術人,其實我們無時無刻都在思考應用與實作。在這個過程中累積了許多有價值的心得。你勞心的成果必有可觀之處,也正是 PyCon Taiwan 所有的參與者想要的東西。

講者是最有收穫的人

在技術分享中得益最多的是誰呢?是分享者。這是真的。施比受更為有福這句話,至少在技術領域裡,並不是道德家的陳腔爛調,而是堅實的經驗法則。站在台上和坐在台下,對題目的掌握程度完全不在一個量級上。在台上作報告的人要花十分的精力先研究清楚題目,再想出方法表達。演講的初稿多半亂七八糟,而要經過多次的修改,從各種角度精進講稿的內容後,才會作出稍微能讓聽眾接受的材料。聽眾只要聽聽看看講者苦心烹調的好菜就行。對講者來說,準備演講是很費力的工作。西諺有云 no pain, no gain。雖然辛苦,但在技術會議裡準備並進行演講,其實是整理技術非常有效率的手段。而因為研討會同時強調講台上下的互動,演講所能得到的意見回饋,通常也大大地快過寫作。

我大約可把上台分享的人略歸為三類。第一是知識型的講者。他們滿富精力,常常會作出一些好有趣的東西,講出來嚇人一大跳。譬如我參加 PyConUS 2011 時,印象最深刻的就是 David Beazley (http://www.dabeaz.com/) 講的 Using Python 3 to Build a Cloud Computing Service for my Superboard II (http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-using-python-3-to-build-a-cloud-computing-service-for-my-superboard-ii-4896844)。David 的技術深度和演講技巧實為一絕。順道一提,David 是 PyCon Taiwan 今年請到的 keynote speakers 之一。這一類的講者通常早已明白分享的價值在於交流,因此樂於投稿,主動尋求與聽眾和參加者互動的機會。

第二類是宣傳型的講者。許多技術或服務的開發者會積極地在研討會發表演講,增加能見度。宣傳型的講者不像第一類的講者單純尋求討論的空間,而期待更有目的性的分享。請不要認為這一類的講者功利。宣傳者同樣樂於分享。他們的分享只是較具有針對性,在求知之外尋求其它的發展機會。因為有實際的應用,所以對與會者來說,宣傳型的講者容易拓展會議的多樣性 (diversity),是非常重要的成員。如果你想交流這類的題目,即使不完全與 Python 相關,PyCon Taiwan 都非常歡迎你的分享。

第三類是學習型的講者。這一類講者也許在演講上不十分有經驗,但投入了相當的精力研習技術。作為學習的一部分,這些講者要花不少時間建構演講的內容,然後上台分享。但在準備的過程中,講者要從許多面向來分析並改進講稿。這是私下研習技術所不容易作到的事。

這樣粗略的分類並不完全,但是方便我分析為何講者在技術分享中得益最多。對 PyCon Taiwan 來說,每一類以及沒有歸到類的講者,都是我們想吸引的對象。這其中最需要被鼓勵的是學習型的講者。如果你認為自己可以歸在這一類,我要繼續向你說明如何透過在 PyCon Taiwan 分享,來更快更有效地精進技術。

如何準備投稿與演講

PyCon Taiwan 並不是同儕審查的學術會議,因此在投稿的時候只需要題目與摘要。你的題目和摘要只需要反應上台時所講的內容即可。在投稿的時候需要把所有的演講內容都準備好嗎?不需要。當然,你也不能外插地太厲害,到時候講不出東西來。不過題目和摘要都是你自己寫的,你自己完全可以控制。

所以你發現 PyCon Taiwan 與大部分其它的 PyCon 都是寫 call for “proposals”,而不是 “papers”,因為我們要你投進來的只是演講的「提案」,而不是演講本身。會後你可以把你的演講內容整理成論文,我們會協助你真的投稿到有同儕審查的 Python Papers (http://ojs.pythonpapers.org/) 去。例如去年在我們 PyCon Taiwan 講 TMSTAF 的 Bevis Lee,已經有文章登上去了 (http://ojs.pythonpapers.org/index.php/tpp/article/view/247)。

請注意,不必過度擔心你的投稿的「品質」。不要怕錯。尤其當你根本沒有投稿或發表的經驗的時候,犯錯實在是再正常也不過的事。你的摘要格式可能不統一或不符合一般要求。摘要內容可能混亂。標題可能不搭配摘要。或者你還會搞出各種大大小小我想也想不到的問題。這些都不該影響到你投稿的意願。當然,為了求進步,你是應該要把演講準備到最好。能不犯的錯誤儘可能都不要犯。但你不要掉進完美主義的陷阱,到最後反而什麼都沒作。你一旦開始準備演講就會不斷地改不斷地改,永遠不會覺得自己作得夠好。這是常態。金庸到這個年紀還在改他多年前的作品呀。說真的,你的演講品質是「我們籌辦者」要擔心的事情。你大可以在這一點上與 PyCon Taiwan 「合作」。PyCon Taiwan 所提供的環境,正是讓你拿來自我鍛練的機會。不要輕易放棄這個機會。

適巧看到 http://blog.roodo.com/ceibaca/archives/2107610.html <重寫之必要> 一文,相當準確地描述了鍛練寫作的方法。其實準備演講的原則也是一樣的,只是對技術演講來說,我們還會考慮到對技術本身的再思索。以下引用我認為最讓人受用的三段。

不幸的是,作家和學者就算有了靈感,也往往沒有辦法一口氣完稿。出於文壇/學界、編輯以及自己的嚴格要求,作家和學者必須不斷重新面對自己的稿件,一再重寫。坊間有時謠傳,有一種作家/學者七步成詩,一周就寫完代表作--但這種人是異數,這種謠傳也誤導人心,對於有心從事創作和學術的年輕人尤其有害。我自己不是那種人--我寫短篇小說時,同一篇小說重寫三次是很平常的事(從第一人稱觀點改成第三人稱觀點;把焦點從女主角移到男主角身上……);我寫博士論文的時候,同一個章節可以讓我重寫一百次(把過氣的甲論點從每一頁抽出;把尖銳的乙觀點植入每一頁)。

不必去羨慕、去效法那種「一口氣天才」,反而該要有不斷重寫稿件的心理準備--重寫的過程,很考驗人的耐心,也往往會挑戰一個人的自尊心;但是唯有忍耐重寫的過程,甚至學習去珍惜這個過程,才可能踏上出版之路。

在寫作路上,在讀研究所的過程中,我看過不少很聰明的同伴--他們極富潛力,但他們無法忍受重寫的過程。他們認為重寫就是恥辱,是失敗。於是他們放棄了筆。留下來繼續寫作和研究的人,其實並沒有比較聰明,而只是比較甘願重寫而已。

結語

去年在 PyConTW 2012 結束後,我已經寫過,今年在議程上的目標絕不能只有翻倍 (http://solvcon.net/yyc/everydaywork/2012/06/15/pycontw2012_finale.html)。但如今的投稿狀況只能讓人用「失望」二字來形容。然而,我知道還有很多人因為種種原因而沒有投稿,故我撰此文,鼓勵所有應投稿而未投稿的人,把你的熱情和用心貢獻給台灣的 Python 社群。講台真的是 PyCon Taiwan 的核心。我向你保證,上台發表的你,不管之前有沒有演講的經驗,都會得到超過你所預期的回報!

不要退縮喔!你的貢獻會壯大台灣的 Python 社群。我們會是一個以技術為核心的群體。用謙卑的態度解決難題,以得著十足的快樂與滿足。你希望我們成功嗎?3/11 之前,來 http://tw.pycon.org/2013/zh/blog/2012/11/21/call-for-proposals-zh/ 投稿吧!

十月 8, 2012
» Multi-Dimensional Taylor Series

Multi-Dimensional Taylor Series

Everyone knows how to write the Taylor series. Given a scalar function f(\xi), its Taylor series can be written as

(1)f(\xi; \xi_r) = \sum_{k=0}^{\infty} \frac{1}{k!}\dod[k]{f}{\xi}(\xi-\xi_r)^k

where \xi_r is the centered point. There is few challenge in obtaining Eq. (1). However, if the function of interest has more than one variable, e.g., u(x_1, x_2, \ldots, x_N), Eq. (1) can no longer be used.

To obtain a formula for the Taylor series of a multi-dimensional function, it is obvious that we should use partial derivatives \partial/\partial x_1,
\partial/\partial x_2, \ldots, \partial/\partial x_N rather than simple derivative \dif/\dif\xi. To insert the partial derivatives, we need to use directional derivative. To proceed, consider a scalar function

u(x_1, x_2, \ldots, x_N)

in an \mathbb{E}^N-space, in which the coordinate axes are denoted by

\bvec{x} = (x_1, x_2, \ldots, x_N)

Let

\bvec{y} \defeq \bvec{x} - \bvec{x}_r

denote a vector pointing from a referencing point \bvec{x}_r to \bvec{x}. The directional derivative of u is then written as

\nabla_yu = \vec{\nabla}u\cdot\left(\frac{\bvec{y}}{y}\right)y
= \left[\sum_{i=1}^N(x_i - {x_r}_i)\dpd{}{x_i}\right] u

Similarly, higher-order directional derivatives can be written as

(2)\nabla_y^ku = \left[\sum_{i=1}^N(x_i-{x_r}_i)\dpd{}{x_i}\right]^ku

Aided by replacing the simple derivative in Eq. (1) with the directional derivative, the Taylor series of u about \bvec{x}_r can be expressed as

(3)u(\bvec{x}; \bvec{x}_r) = \sum_{k=0}^{\infty} \frac{1}{k!}\nabla_y^ku

Substituting Eq. (2) into Eq. (3) gives

(4)u(\bvec{x}; \bvec{x}_r) = \sum_{k=0}^{\infty}
  \frac{1}{k!} \left[\sum_{i=1}^N(x_i-{x_r}_i)\dpd{}{x_i}\right]^k u

Equation is the Taylor series of a multi-dimensional function u(x_1,
x_2, \ldots, x_N).

It should be noted that symmetry of the higher-order partial derivatives is not assumed. That is, the mixed partial derivatives are not commutative.

八月 13, 2012
» Python to COSCUP

Python to COSCUP

這個週末就是 COSCUP 了,而感謝 littleq 的奔走,今年我們 Python Taiwan 會有一個攤位

我們會在 COSCUP 的 Python 攤位準備之前為 PyCon Taiwan 製作的貼紙和手冊,給大家作紀念。不過更重要的是,攤位有安排時段作 Python 的火力展示,時間表已經寫在 http://j.mp/NwDmqq 了,請大家一起來我們的攤位坐坐。目前我們還有一些留空的時段,各位寫 Python 的朋友,請你們一起來參與展示活動,趁 COSCUP 這個機會來 Hack!Python

即使你沒打算展示什麼東西,我們也很需要你來幫忙顧攤。熱心的朋友們,請來 http://j.mp/Pf22Wa 填一下顧攤的時段。除了 happy hacking 之外,我們也可以來聊聊明年的 PyCon Taiwan。萬事待興,非常有趣。

對我們的 Python 攤位有任何疑問,可洽詢負責人 littleq,或者到 http://groups.google.com/group/pythontw/ 或 Freenode/#python.tw 來聊聊。

六月 24, 2012
» Code for Results

Code for Results

I’d like to record some of my thoughts on how to improve the quality of scientific codes.

Programming for scientific problems is difficult. It is intrinsically a multi-discipline task. To develop efficient code to model interesting phenomena, a researcher needs to know well about his problem, computer architecture, various programming techniques, and many numerical analysis skills. After the code can finally be compiled and run, it needs to be tested, debugged, and verified for all target machines (and platforms). Then we know the results are correct, reproducible, and trustworthy.

For collaboration, there are more things to do. If the code is intended to be released to peer researchers, it should be designed with comprehensible API. If there would be general users who are not expected to touch the internals, the API must be organized to allow building a user interface and/or a scripting layer. And a guide to the software system should be provided. But perhaps more importantly, the code should be available to all collaborators, and potential collaborators.

Unfortunately, things do not always work that well. It is common to find a program that can only run on the machine it was developed on. It is common to find a program contains 5,000 lines of arbitrarily-indented code in a single file. It is common to find a program shipped with no or an out-dated manual, and users have no clue to run an example problem. It is so easy for a scientific code to become unmaintainable, and its source is usually not publicly available to reveal the fact.

In general, without a clear structure, version control, unit tests, API documentation, rerunnable examples, no one can be sure that a code really does what it claims. Although the developers usually know what they are solving for, the beauty of their work is covered by the dust of unconvincing development practice.

Producing monolithic, ill-organized, limited-use code isn’t anything that we numerical analysts feel proud of. The status quo should really be improved. I am going to write down what I think would be helpful for practicing scientific programming.

Openness

Software development is on magic. It is just an intellectual-intensive activity involving computers. When talking about intellectual development, the importance of openness cannot be overemphasized. An open society gestated the modern high-tech civilization that we are enjoying. An open environment is needed to enable the mind sharing for software development.

Such an environment should enable collaboration at the source-code level. Although many efforts have been made to shape software into components, no software is simple enough to evade source-level reviewing. Moreover, just like a normal person weaves his thoughts by using a natural language, a competent programmer thinks in a programming language. The most efficient way for programmers to collaborate is to use (well-written) source code, not diagrams, slides, reports, or anything else.

Thus, we can conclude that open-source is a straight-forward approach to respond the need for productive collaboration. It should be noted that open-source has nothing to do with free-of-charge software, although many open-source projects use free for marketing. The source-level collaboration enabled by the open-source practice introduces new business models. In the new models, software can be developed by using fewer resources.

For a long time, software is regarded as a large chunk of compiled binary that hides most of its internals and exposes only a limited amount of user interface. However, things do not need to be done in this way. In the past two decades, the widespread Internet and WWW have added new rules to the game. The open-source practice has helped new giants like Yahoo, Apple, Google, Facebook, and many other new-style software companies to win over the past invincible opponents like Microsoft, which just started to catch up in the race.

The trend of open-source will arrive everywhere that demands software. Aided by the successful marketing actions led by IBM and RedHat, the open-source Linux operating system defeats SCO UNIX, Microsoft Windows, and many other close-source competitors in the server and HPC market. In the Top 500 list of supercomputers one can rarely spot a system not running Linux. The tool chain of scientific computing is also full of other open-source software, e.g., GCC, MPI (MPICH1/2, MVAPICH1/2, or OpenMPI), LAPACK, FFTW, to name but a few. Open-source will help our pursuit of productivity in software development.

Hierarchical Software Stack

Scientific computing needs a hierarchical software stack. One reason to do so is to hide the complexity of the computing problem. On the one hand, engineering or scientific problems involve a huge amount of computation and need low-level access to the raw metal for ultimate runtime efficiency. On the other hand, the complex mathematical expressions that describe the technical problems encourage practitioners to employ high-level programming techniques to write comprehensible code. The polarized demand would shape the computing software into multiple abstraction layer.

Another equally important reason for a hierarchical structure is the protection of sensitive information. From the security point of view, it is ideal to open-source the fundamental computing platform as a framework, while protecting business secrets in a lower-level, compiled layer.

In general, an easy-to-use, high-performance system for scientific computing cannot be productively built by using an overarching tool or language. Conventional approaches are either too costly (in terms of labor and money) or unable to deliver (the runtime performance). But perhaps the most serious issue with the conventional approaches is the lack of outlook. Bleeding-edge hardware of heterogeneous architecture and the ever-increasing gap between the floating-point efficiency and the memory operation efficiency call for renovated software. Developing monolithic code does not address the new needs.

In fact, vendors of scientific software have already recognized the need, and structured their product into layers. They either implement a proprietary scripting language or use an existing one, to provide an easy-to-use platform for automation and/or parametric study. The scripting layer is built on top of its core framework which realizes fundamental numerics. One can find this design in leading companies in almost all major application fields such as MATLAB (general numerics), ANSYS (computational mechanics, fluid dynamics, electromagnetics), 3DS/ABAQUS (computational mechanics), Autodesk (computer aided design), and Synopsys (electronic design automation), to name but a few.

Although multiple abstraction layers have been materialized in these proprietary software products, there are still many barriers preventing users to gain higher productivity by accessing the internals. In this regard, I think the proprietary approach will be challenged by the users who persistently demand more and more flexibility and productivity. Many people would be drawn to the open-source approach.

Prototype as Product

Based on the hierarchical design and the open-source practice, a new breed of scientific software can be produced. In the past decade, new paradigms of developing software emerged from the need to rapidly develop web applications. Contrary to scientific software that would be used for decades, web applications usually live for only months if not weeks. As a result, web developers tend to use any means to shorten the time to market, and become the most active supporters of the open-source practice. They routinely use high-level languages for prototyping and the turn the prototype directly into a product.

This prototype-as-product approach is promoted by recognizing two facts: (i) Developers are expensive and (ii) computers are relatively cheap. Prototyping is not a new concept, but in the past, a high-level prototype is usually reworked into a product, after the proof-of-concept, by using a different and lower-level language. The hasty pace of the web world broke the boundary between prototypes and products to squeeze all the productivity out of the workflow. Optimization is postponed to a later stage of the development.

Although the experience of the web world cannot be equivalently copied into scientific computing, the spirit should be borrowed. What practitioners of scientific computing care is the turn-around time to results, which includes both development and running time of the software. The new paradigm can deliver reliable code in a shorter time than old approaches can.

As long as the performance hotspot in a prototype can be properly optimized, a prototype-turned product can deliver ideal runtime performance. It is not uncommon for an optimized prototype system to exhibit the same runtime performance as a system implemented by using solely a low-level language like C, C++, or Fortran. For example, some new projects have been developed by combining Python and a low-level language, e.g., FEniCS/DOLFIN, FiPy, Kestrel, and SOLVCON. The hybrid approach is also favored by the heterogeneous architecture, which intrinsically requires the developers to use multiple programming languages.

Final Words

Scientific computing has driven the development of digital computers from the very beginning. Computers are invented to solve technical problems, as the infamous ENIAC, the first general-purpose electronic computer, born in 1946, developed to calculated artillery firing tables. In the era that hand-held devices delivering the computing power unimaginable from a decade ago, the need for scientific computing will continue to fuel the development in all aspects of computation. And we should write better code to do it.

六月 15, 2012
» PyCon Taiwan 2012 與台灣 Python 社群的啟動

PyCon Taiwan 2012 與台灣 Python 社群的啟動

謝謝各位,讓我們這群 Python programmer 渡過了一個愉快的週末。不,是超級快樂的週末才是!

我們很成功地在台灣舉辦了第一次的 PyCon (Taiwan)。包含籌辦人員,總參加人數達到了 250 人。如果還有人說台灣寫 Python 的人很少,那肯定只是因為他沒用心找。

這次大會的籌辦,還要感謝協辦的 OSSF 和幾個贊助單位。因為有他們在人力物力和財力上的協助,讓籌辦方可以無後顧之憂地準備議程和活動。當然,也不能忘了辛苦的工作人員們:marr, hychen, timchen119, niki, timhsu, andy, channing, david, jacktsai, kanru, keitheis, lichain, littleq, lloyd, mat, minkenhsu, peterwolf, tcc, terryhuang, pct, strong, tjw, tzangms, yenlung, yurenju,以及我們的顧問 pingooo。

我想在 PyCon Taiwan 的籌備人員中,我可能是出力最少的人了。或許我唯一的功勞,就是在去年 (2011) 五月的時候,開始和 thinker 與 marr 討論在 2012 年正式舉辦 PyCon Taiwan 的想法 (也許有些人聽到的版本是六月或七月,那是因為我的記憶混亂了;剛剛查了一下信箱,相關的信件往來可以追到去年五月)。我大概是少數蠢到想在台灣硬幹一個這麼貴的研討會的人。希望大家都覺得值得!

在大會結束之後,你可以在 http://www.flickr.com/photos/pycontw/ 看到 yurenju 辛苦為我們照下的照片。也可以到我們的 mailing list (google group) https://groups.google.com/d/forum/pythontw 來討論技術,到 Facebook group http://www.facebook.com/groups/pythontw/ 社交,或是到 Freenode/#python.tw IRC 頻道和幾十個流連忘返的 nick 閒扯。

我想邀請各位,透過各種你喜歡的方式,延續我們在 PyCon Taiwan 2012 中所感受到對技術的熱情 (和熱愛)。不要忘記自己是一位 Python user、是一位 Python developer。你正在使用一個非常棒的工具,而它有一個非常棒的社群。這兩者足以支持你完成那些最瘋狂的夢想。然後,我希望明年我們可以看到超過今年一倍以上的參加者,也就是 500 人的大會。當然,為了維持品質,PyCon Taiwan 還是會把握住 everyone pays 的原則,但會作得更完善。

這當然很瘋狂,不過我覺得其實也不會比今年的目標瘋狂太多。畢竟在今年的大會中,各位參加者在會前就填滿了所有開放的 250 個名額,以致於我們無法開放現場報名 (也真的拒絕了一位慕名而來的朋友,很不好意思)。報名的熱烈程度其實稍微超過了籌辦方的預期。再者,從 PyCon Taiwan 2012 現場的活潑氣氛來看,我認為要在 PyCon Taiwan 2013 看到 500 個蟒人跑來跑去,並不是不可思議的事。相信參加了今年大會的各位肯定很有意願在明年呼朋引伴 (也請你務必這樣作,還是你已經開始在拉了呢?) 而籌辦方這邊在累積了今年的經驗以後,明年也要準備得更充份。

不過 500 人的大會不是開玩笑的。為了服務今年的 250 位同好,籌備團隊的成員超過了 25 個人。如果要服務 500 個人,那明年的籌備團隊至少要有 50 個人以上。就算真號召得到這麼多志願者 (別忘了籌備團隊成員也是得買票入場的),組織也是一大挑戰。

再來,就算有足夠的志願者,也能夠進行良好的組織,明年是否能端出讓 500 位同好興奮的議程呢 (大家應該會覺得我們今年技術議程的品質算是不錯的)?這完全取決於我們這些在台灣的 Python 開發者,願不願意開始把自己使用 Python 的經驗拿出來分享給大家。今年我們只收集到了有限的 (18.5 個) 演講投稿,再加上主題演講,最後有 20 個技術演講。對一個剛起步的技術會議來說,這個表現不算差。不過明年的技術演講肯定要比今年多個幾倍,才有可能讓 500 個人都開心。

組織地區型使用者群組

為了進一步發展我們台灣的 Python 社群,我想趁著 PyCon Taiwan 結束後的氣勢,鼓勵有興趣的人在你的工作或居住地周邊,來組織使用者群組。事實上,除了一年一度的年會之外,技術社群更需要的是頻繁聚會的使用者群組,PyCon Taiwan 為社群所提供的,有點像是十年磨一劍的發表會。而因為 PyCon Taiwan 一年只辦一次,所以必定能聚集足夠的資源,邀請世界級的技術領導者,來為同好提供尖端的技術資訊和洞見。地區性的使用者群組 (譬如說,「南港 Python 同好會」或是「埔里 Python 使用者群組」之類) 則讓我們這些愛好 Python 的人,有一個最輕鬆的場合來談論技術,甚至合作專案。

我們是一群搞技術的人,不管活動辦得多大或多小,心裡所想著的都是發展技術。我們肯定不希望只有在辦 PyCon Taiwan 的幾天裡可以和別人聊 Python。我們想要把我們所認為最好的技術用在工作上,作出最棒的系統,盡力幫助我們所關心的人群。我想這是工程道德的一部分。要讓新穎的技術進入產業界需要企業家精神和時間,不是一蹴可及的。PyCon Taiwan 希望能開始將 Python 引入台灣的產業中間 (由於各行各業現在都大幅地資訊化,故此所指的產業不限於資訊相關產業)。在舉辦了一次成功的 PyCon Taiwan 2012 後,希望能號召熱愛技術的人士,透過組織使用者群組和地區性的聚會活動,延續 PyCon Taiwan 的氣勢,合力拓展 Python 的應用。

地區性的使用者群組可以引發很大的力量。始於去年 (2011) 九月,我在竹科旁邊組織了 PyHUG,而許多人可能會發現,PyCon Taiwan 2012 有不少工作人員和講者是從 PyHUG 裡出來的。從 PyCon Taiwan 的角度來看,即使是這麼年輕的使用者群組,都有很大的正面幫助。這真的很棒。希望能有許多的熱心人士,在各個城市或區域組織類似的活動。

在 PyCon Taiwan 結束時,我有提到正在準備成立 (台灣) 蟒協 (正式名稱未定)。使用者群組,甚至 PyCon Taiwan 的籌備團隊,其實都是鬆散的組織,很難凝聚我們這些技術人員之外的資源。成立之後,蟒協可以負責處理正式組織中必然會出現的官僚工作和庶務,讓愛好技術的人可以專注在技術,而不必被 Python 社群所需要的財務、聯繫、公關等等工作干擾。

請回應 Python 使用者的需要,起來成立使用者群組吧!來做吧!明年的 PyCon Taiwan 肯定會讓我們都大吃一驚的。

五月 10, 2012
» 蟒員前進

蟒員前進

離 PyCon Taiwan 還有一個月。你準備好要迎接這個聚集全台 Python 程式員的大會師了嗎?

雖然這是台灣第一次舉辦 Python 年會,但報名的情況超乎預期地踴躍。籌備團隊一度想要提高人數限制,不過評估了我們這些志願者的精力和時間以後,還是決定維持 250 人的上限。如果明年我們可以召募到更多的志願者,會再考慮擴大規模。

PyCon Taiwan 期望藉由合理的收費,聚集目標相合的開發者與從業人員。包括籌備團隊在內,所有人的收費標準都是一樣的。我們最關心的是與 Python 相關的各種軟體技術。希望在這個會議中,大家都拿出最好的東西,彼此切磋。不過,因為有 PyCon Taiwan,我們也許會登峰造極而後求敗,但卻絕對不會孤獨的。

無論你今年有沒有佔到講台,請各位都準備好你的傢伙。閃電秀 (lightning talk)、榮團會 (BoF) 也都是你表現的舞台。在這個台灣 Python 年會中,到處都是 Python 程式員。我們聽得懂 __init__()__call__()@property!千萬不要放過這個一年一度的大會。

如果你還沒有報名,快點。人數上限就是 250 個,再等下去就沒位子了。

四月 15, 2012
» 2012 台灣 Python 年會開放報名

在大家的努力之下,2012 台灣 Python 年會 (PyCon Taiwan 2012) 終於在今天開放報名了。議程也同時出爐。感謝許多投稿者與志願工作人員,再一個半月,我們就會在台北舉行台灣第一次的 Python 年會。Happy learning, happy hacking.

早鳥票的價格為新台幣 1,300 元整,開放到 2012 年 4 月 30 日為止。一般入場券的價格為新台幣 1,500 元整,從 2012 年 5 月 1 日開始,一直開放到 2012 年 6 月 1 日為止。我們還設計了個人贊助票,價格為新台幣 3,000 元整。若您熱情支持台灣 Python 的發展,或是您的公司願意補助購票,可以選擇個人贊助票,來幫助 PyCon Taiwan 2012 籌備團隊提供更佳的會議品質。如果自己掏錢購買個人贊助票的朋友願意公開身份,籌備團隊很願意將您的名字 (或網路 ID) 及網誌連結放到 2012 台灣 PyCon 年會網站裡的「PyConTW 好朋友」。

會議註冊使用 Registrano 的系統,請到 http://registrano.com/events/pycon-taiwan-2012 報名。依照 PyCon US 的傳統,PyCon Taiwan 2012 也是參加者付費的會議。所有義務工作人員和講者均自行付費參加。一旦報名確認後不會予以退費。

注意,名額有限。早報早好!

三月 4, 2012
» 創新的權力

來為自己爭取創新的權力吧。請來參加在今年的六月九、十日所舉辦的台灣 Python 年會,構築在地的 Python 社群。

創新成功有許多條件。老實說,技術能力或許不能算是最重要的一個。然而寫程式不容易,寫好程式更加不容易。如果想要快快樂樂搞些有趣又前無古人的東西,不在技術上面下功夫是不行的。畢竟你大部分的精力可能得用來處理一堆亂七八糟的事情。如果連手上的程式也一起進來攪和的話,或許也不必等敵人來攻,就會被自己的體重壓垮了。

Python 程式語言以其簡潔與功能,在二十年的發展過程中累積了許多忠實使用者。Python 的 web framework 比它的關鍵字還多,而 Python 也是科學家們最愛使用的程式語言。作為創意的載體,Python 完成許多工作,推進世界的進步。在台灣,Python 也已是資訊技術人員的重要工具。

Python 是重要的創意工具。我們要藉由 PyCon Taiwan 的發展,用 Python 來全面提昇這塊土地的能力。

我們已經開始徵求講題,歡迎對 Python 有興趣的各界人士投稿。如果你暫時還沒有要分享的題目,那麼請密切注意註冊開始的時間,在六月的第二個周末來台北和我們一起共享 Python。

二月 18, 2012
» 馭蟒人出列

馭蟒人出列

PyCon Taiwan 2012 將於民國一百零一年六月九、十日,在中央研究院人文社會館舉辦。

台灣的 Python 社群在 2008 年和 2011 年由 thinker 主持的 PyCTW 之後,迎來了正式的 PyCon Taiwan。我們要在台灣辦一個專屬於 Python,規格完整的研討會,讓所有正在用、想要用,以及曾經用過 Python 的人都來享受 Python 之樂!

我們已經開始接受演講提案。會議主題非常廣泛,只要是與 Python 有關的題目,我們都無比歡迎。沒有 Python 做不到的事情,不是嗎?提案的截止日期是四月,請把握時機!演講可以中文或英文進行。

PyCon Taiwan 也需要更多幫手!雖然這是台灣第一次正式舉辦 PyCon,但我們相信會有非常多參加者。我們需要很多會務人員,讓我們能夠保證會議的品質和 Python 程式碼一樣好。

台灣的馭蟒人出列吧!PyCon Taiwan 也會遵照 PyCon US 本店的 Everybody Pays 原則,對每一位參加者收費。不管是籌辦委員會主席的不才在下我、投稿的講者、熱情的會務伙伴,或是單純前來參加會議的人,都會用自己的錢包支持台灣的 Python 社群。人的錢財在哪裡,心也在那裡。Python 和 PyCon Taiwan 是值得我們用心的對象。

有任何疑問,歡迎寫信到 organizers@pycon.tw 來問我們。記得,把六月九、十日留給台灣 Python 年會!

Pythonites Roll out

PyCon Taiwan 2012 will be held on June 9th and 10th at the Building of Humanity and Social Sciences.

Taiwan Python community now have the official PyCon Taiwan, after the PyCTW in 2008 and 2011, which is organized by thinker. We will make a full-featured conference specific to Python. Everyone who is using, will be using, and has been using Python can join us to embrace the beauty of Python.

We are soliciting talk proposals. There is a wide range of topics accepted by PyCon Taiwan 2012. There is nothing that Python cannot do. Just send your proposal to us. Call for proposal will be closing in April. Don’t be late! The talks can be in Chinese (Mandarin) or English.

We need more helpers too! Although it’s the first PyCon Taiwan, we believe there will be so many people come to join us. The more staff members the better. We want the quality of the conference to be as good as that of Python code.

Taiwan Pythonites roll out! PyCon Taiwan will follow the everybody-pays rule of PyCon US. The chairperson of the PyCon Taiwan Operation Committee, speakers, enthusiastic staff members, and everyone coming to the conference pay for their registration.

Should you have any question, don’t hesitate to ask us at organizers@pycon.tw. Mark June 9th and 10th on your calendar for PyCon Taiwan now!

十二月 4, 2011
» PyHUG 圖示決定

投票的結果揭曉,是候選人三號以 22 票擊敗了二號的 14 票及一號的 12 票,奪得最受歡迎的圖示寶座。因此 PyHUG 現在正式地有圖示了。

http://photos4.meetupstatic.com/photos/event/5/8/0/e/600_76882542.jpeg

謝謝各位朋友們的寶貴意見!

十一月 26, 2011
» PyHUG 圖示重新投票

為了 PyHUG,熱心的 Peter 出馬為我們設計了三版不同的新圖示。希望各位關心 PyHUG 的朋友,幫我們到 http://www.surveymonkey.com/s/RB88D99 再投一次票,決定 PyHUG 的圖示!

投票時間開放到本月月底,十一月三十日二十三時五十九分 (GMT+0800)。謝謝大家!

十一月 12, 2011
» 再次徵求 PyHUG logo

這是一則早該進行的說明啟事。

早在七月,熱心人士協助我們依據 Python Trademark 的精神,設計了一個 PyHUG logo。然而我沒有注意到的是,Python trademark 的所有人,Python Software Foundation (PSF),並不鼓勵和 Python logo 相似卻不同的外形設計。PSF 的立場是,使用者群組的 logo 要完全採用 Python trademark 的外形,但可以改變顏色。不然,就希望能不要參考 Python trademark。更詳細的前因後果,請見這裡

我們與 PSF 溝通了一段時間,最後決定依照 PSF Trademarks Committee 的建議,另外設計一個 logo 給 PyHUG 使用。畢竟我們原本的 logo 是大家所選出來的,若要更改,也應該再公告一次,交給大家決定。

因此,弊人要再次為 PyHUG 徵求一次 logo。如果你願意幫忙,十分希望能與我聯絡。

九月 5, 2011
» PyHUG First Meeting Moves to September 19, 2011

我們大意了。PyHUG 原本訂於九月十二日的初次聚會適逢中秋假日。為了不要造成大家的兩難,我們把聚會的時間移到次週一,也就是九月十九日的同一時間:民國壹佰年玖月拾玖日週一晚間柒時參拾分。

詳細資訊請再次參見吾等的公告。

八月 20, 2011
» PyHUG First Meeting on September 12, 2011

讓大家久等了。Python Hsinchu User Group (PyHUG) 首發聚會訂於民國壹佰年玖月拾貳日週一晚間柒時參拾分。

詳細資訊請參見吾等的公告。

關於我們的 logo,因為弊人大大地不察,造成了版權的問題,使得之前票選出來的美麗圖示無法使用。實在萬分抱歉。不過新的版本正在努力生成中,相信很快就可以和大家見面的。

八月 3, 2011
» PyCon 2012

http://pycon.blogspot.com/2011/08/pycon-us-2012-official-launch.html

明年舉辦的 PyCon 2012 將會比往年更早開始徵求 (call for) 演講 (talk)、教習 (tutorial)、海報 (poster),也會提供關於如何撰寫提案的說明。有興趣的諸君,可以開始準備了。

七月 26, 2011
» PyHUG 圖示喜好調查結果

總票數為 89。一號圖示得票數為 39、二號為 14、三號為 36。一號圖示以三票之差取得圖示寶座。

感謝各位的踴躍投票。為了一個還沒正式成立的地區使用者群組,在幾天之內有近一百人參加投票,令我頗感振奮。不是我自誇,本小站和 Python@TW 郵件列表都可以用人氣低落來形容。有這麼多人對 PyHUG 感興趣,很令人開心。我想主要還是因為 polly 幫我們設計的圖示都很好看的關係吧!

我正在和 PSF 取得聯繫,讓他們知道我們新作的圖示。完畢之後就可以掛上來用了。新竹地區的 Python 用戶們,敬請期待秋天開始的活動!

biggo.com.tw

A Django site.