New Year's Resolutions

Categories: resolution, goals, fpga, lisp, turbogears, python, programming

Well, in the spirit of the season, I will give my top 10 technical-related New Years resolutions (or goals, or whatever name you prefer).

10. Sign at least 3 customers up for ConsulTracker.com - This should (hopefully) provide some low-effort recurring income, as well as get my web coding skills up to snuff. We'll say one customer by February, another by May, and a third by August.

9. Attend most (if not all) of the Python meet-ups in Atlanta - I really need to get more involved in the community. When I wrote my little TurboGears/Django/Subway comparison and got a comment from Kevin Dangoor (the main force behind TurboGears), it just about made my day. I always kind of looked at the big FOSS programmers as these uber-coder celebrities. Nice to know they're not inaccessible. And there might even be some contributions I could make.

8. Develop at least 2 new applications - Well, could be one new application and major feature enhancements for ConsulTracker. I'm thinking of a customizable workflow management system. Kind of like a bug tracker, but more generalized. It would let you take orders, route them to the warehouse, generate invoices, take payments, etc. It will be rule-based, have email notifications, and be scriptable in Python (for business rules). As to the major ConsulTracker feature enhancements, I'm looking at adding an expense reporting feature as well a traditional timeclock feature for hourly employees (not consultants). The timeclock would need a lot of custom logic for overtime, etc. I'd like to make it customizable to the individual business, but there's some thinking to do there.


7. Do something interesting in LISP - I'm really intrigued by the language, I use EMACS, I've copied and extended a LISP HTML templating library, but I've never really done anything real. I kind of look at languages in four productivity categories (roughly 3-10x improvement per class): C/C++ ==> Java/C# ==> Python/Ruby/Perl ==> LISP/Scheme. I can vouch for at least some of the languages in the first three categories, but I'd like to see what LISP can really buy me in productivity.

6. Publish GRACE technical report - This one really should have been done a few months ago when it was written, but look for it in the first few weeks of 2006.

5. Publish at least three papers as lead author - Not including the technical report, I really need to get into some peer-reviewed journals/conferences. I've submitted to DAC, but who knows if it'll make it. And that's three acceptances, not necessarily publications (for conferences in 2007, etc.). This will likely take the whole year (to get all three).

4. Extend the GRACE backend to handle all the little things I've been considering - like shared functions, shared functional units, bitwise cell characterization and full static timing analysis. This should get me from "competitive" with hand designs to "better most of the time." GRACE needs to be able to traverse the area/time design space in the micro (at the level of functional units), not just the macro (at the level of loops).

3. Extend the GRACE frontend to handle all the little things I've been considering- like (basic) object-oriented programming, better data structures, macros, array dependence analysis, and a real C/C++ front-end. Since the value proposition of GRACE is improving hardware designer productivity, the language level needs to be raised. For hardware, I see the productivity classes as VHDL/Verilog ==> Handel C ==> C/C++/SystemC/etc ==> HumIR (now) ==> HumIR (4Q2006). The goal is to improve HumIR enough to merit an increase in productivity class.

2. Do something interesting with GRACE - My research group is currently looking at using GRACE to synthesize (parts of) an H.264 encoder or decoder. That might satisfy this requirement, or maybe I need something more extensive. To get mindshare (and eventually marketshare), GRACE will need the archetypical "flashy demo." Small amount of HumIR code (less than 1000 lines, I'd say), FPGA or structured ASIC platform, pretty pictures.

1. Propose my thesis - Somewhat dependent upon the papers above, I need to at least have my thesis proposed by next December. That means doing a whole lot of other things as well, like re-enrolling in school, etc. It also means a lot of reading of papers. I hope to have a draft by July, final version by October, accepted by December. (Arbitrarily chosen dates, but at least something to shoot for.)