PyWacketPyWacket|
Project /
LessonsLearnedProject.LessonsLearned HistoryHide minor edits - Show changes to output Changed line 22 from:
to:
Desktop GUI applications are great to have, but a good console application can run on a Linux server and that's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of [[http://www.tornadoweb.org/en/branch2.1/websocket.html | Tornado websockets]] are also very impressive and powerful. Added lines 1-49:
!!!Lessons Learned The evolution of the project has been interesting. In the last two years, some of my ideas about this project have changed - progressed I hope. !!Using Python to the Max My understanding of Python technologies has also evolved over the last few years, but the basic idea for the project has also evolved. Keep it simple, do one thing at a time and do it well, never ever ever repeat yourself. Keep it as Pythonic as possible, use the built-in standard library modules ( like multiprocessing ! ) as much as possible. !!Simple Well-Designed GUI Applications Simple, well-designed desktop applications functions can be very useful. A small host of Python applications ( the [[http://www.exaile.org/ | Exaile music player]] for example ) can provide of core for a 'run anywhere' desktop. There are also tools and techniques that meet many different integration needs without any Python coding or coding of any sort. For instance, X-Forwarding combined with [[https://www.cygwin.com/ | Cygwin]] on Windows platforms can be extremely useful. A couple of relatively slow machines can split the graphics workload from the applications workload and produce roughly twice the throughput as a single machine. With X-Forwarding via Cygwin, an insecure Windows machine can hide behind a secure Linux machine, without the overhead of running a virtual machine. In fact, any overhead can be split over two less-than-state-of-the-art machines. !!Simple Well-Designed Console Applications Overall, desktop GUI applications are a still part the project but not as much as they were from a Python perspective. A good console application can run on a Linux server and that's very good functionality to have for an integration platform. Decent web browser 'monitor type' applications are also valuable for Linux server-side functions. Some demos of [[http://www.tornadoweb.org/en/branch2.1/websocket.html | Tornado websockets]] are also very impressive and powerful. !!Focus on Linux Server Integration, Simplify It ! More important than code is the overall infra-structure and configuration management, servers, inter-process messaging, etc.. In addition to graphical desktops, GUI-free/Python-enriched servers are also within the project scope and promise to make the inner workings of servers much more visible and much easier to administer. !!The Three S's - ''S''ecurity, ''S''ecurity, ''S''ecurity. The projects above started from a general interest in Python, but more specifically and urgently as a result of the insecurity of PHP web applications on the old [[http://billbreitmayer.com | BBcom site]] ( soon to be an HTML-only site) . To make a long story short, the bad hackers beat the snot out of me. Maybe I will have better luck and more control over security running Python apps. !!Develop Concrete Usage Scenarios Anything is possible, anything is doable .... in theory. In practice, smaller is better. The cyberworld ( especially the Python cyberworld ) is littered with high-quality, but enormous application frameworks that may comprise many thousands of lines of code. They can accomplish a huge range of functions, almost anything you can imagine and some things you never thought of. [[https://www.djangoproject.com/ | Django]] is a good example, it's a very good framework and works well for big applications. But it seems to be that for desktop level apps, smaller frameworks do the best job accomplishing a specific task. So the upshot is keep requirements simple and under control. It has been said that one good question is worth more than any number of useless answers. Tight, focused usage scenarios help to nail down what actually needs to be done and prevent the 'scope creep' that plagues so many software applications. !!The Known Unknown Note that this is just an entry point into these projects - the schedule for the whole thing is pretty vague. For example, the timeline for the [[RuleForge]] has been repeatedly revised from period of several months to several years, a schedule slip of about 1000% ... so far. At 10 hours per week, it could take several years ( more! ) to build to a concrete inference engine application. |