Slashdot Mirror

1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress, regardless of whether you like PHP/MySQL or not.

2. Use a subscription/payment management company. You're just a small group of nerds, not accounts receivable clerks. Fastspring, Plimus are free; Chargify, Subsify, Cheddar Getter, BrainTree, Spreedly charge; and Zuora is expensive.

3. Use Google Docs and Slideshare to share documents.

4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype, Jabber, SIP

5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim, Projly, DokuWiki.

6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.

7. Someone mentioned version control. Use git if you're a cool kid. Or svn if you're old and busted. Read the RedBean book. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN (integrates into Windows Explorer).

8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit, PHPUnit, FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development.

9. If you're writing tests, that implies loose coupling, which might require dependency injection. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.

10. Development processes: Scrum, Extreme Programming. UML lets you communicate graphically about objects.

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

This has already been around since 1997 I believe, and it's already popular.

Not necessarily. UML is mostly useful to app-level programmers (and those who work with them), whereas UML is mostly useful to sysadmins and system-level programmers (with whom UML, to the best of my knowledge, has never really caught on).

I'm at least a nominal member of all three sets, and I work much more with UML than UML.

Not necessarily. UML is mostly useful to app-level programmers (and those who work with them), whereas UML is mostly useful to sysadmins and system-level programmers (with whom UML, to the best of my knowledge, has never really caught on).

I'm at least a nominal member of all three sets, and I work much more with UML than UML.

Not necessarily. UML is mostly useful to app-level programmers (and those who work with them), whereas UML is mostly useful to sysadmins and system-level programmers (with whom UML, to the best of my knowledge, has never really caught on).

I'm at least a nominal member of all three sets, and I work much more with UML than UML.

Until I got to the end of the blurb I thought this was about user mode linux...and now, of course, I have no idea what it is.

Well, I'm definitely not trying to troll here or anything, but in this instance I'd be willing to give the poster the benefit of the doubt on the TLA use here. Given the target audience (Slashdot tech-heads), and the prevalence of UML in the tech field (among other things there are literally hundreds of available books on the modeling language, but no easily found ones on User Mode Linux), it's not that unreasonable to assume that most would know the Unified Modeling Language, and that those aware of User Mode Linux would fall in the group that probably 'should' know about the UML.

Of course, writing it out long-hand is always handy, and a few links sprinkled around could help.

Until I got to the end of the blurb I thought this was about user mode linux...and now, of course, I have no idea what it is.

Well, I'm definitely not trying to troll here or anything, but in this instance I'd be willing to give the poster the benefit of the doubt on the TLA use here. Given the target audience (Slashdot tech-heads), and the prevalence of UML in the tech field (among other things there are literally hundreds of available books on the modeling language, but no easily found ones on User Mode Linux), it's not that unreasonable to assume that most would know the Unified Modeling Language, and that those aware of User Mode Linux would fall in the group that probably 'should' know about the UML.

Of course, writing it out long-hand is always handy, and a few links sprinkled around could help.

Until I got to the end of the blurb I thought this was about user mode linux...and now, of course, I have no idea what it is.

Well, I'm definitely not trying to troll here or anything, but in this instance I'd be willing to give the poster the benefit of the doubt on the TLA use here. Given the target audience (Slashdot tech-heads), and the prevalence of UML in the tech field (among other things there are literally hundreds of available books on the modeling language, but no easily found ones on User Mode Linux), it's not that unreasonable to assume that most would know the Unified Modeling Language, and that those aware of User Mode Linux would fall in the group that probably 'should' know about the UML.

Of course, writing it out long-hand is always handy, and a few links sprinkled around could help.

Starting with the obvious. Any other good places to direct the novice and experienced?

I suspect a lot of people here are. To me, and probably to most of them, UML is Unified Modelling Language. Hell, do a google search for UML and the top hit is to the UML website.

I know it's too much to ask OSS projects not to pick confusing acronyms and names, but I'd like to think that story submitters or at least editors could a little clearer.

Oh, you meant User-mode Linux? Well, why didn't you say so? Sometimes I think these writeups are intentionally confusing.

• Persistent and temporary file formats
• User interface
• Network protocols
• System and architectural design
• Relationships between data elements (or objects if you think that way)

However, these languages are very difficult to learn and this can get in the way of learning other facets of programming and computer science. This learning curve impacts the learning of the general problem solving skills needed to work outside the limited world of discrete finite machines, such as in networking or inter-personal spaces. Java solves some of the problem in the OU cirricula by providing a "lite" language. It is a language that does impressive things very easily and that gaurds the programmer against some nasty complexities like platform/compile/library incompatabilities. These are also the reasons it is popular in industry. Languages such as Fortran and Cobol hold on in our Science and Business colleges because of legacy code and the personal perceptions of the faculty. Unfortunately you can improperly teach the problem solving ciritcal to progammin in any language, just as you can properly teach without a language. Classes that focus on getting design and thought about a problem started at least during if not before a project would be much more helpful. Systems such as OO pattern and tools like UML provide much help to the Software Engineer and Computer Scientist alike.

I've worked in the *real world* Perl, C, C++, Z80 assembler (in embedded and non-embedded environments) and Java. Each has a different goal and a different way of getting their. However, irregardless of the path taken, they achieve those golas to a limited degree. Oak, the language that became Java, was designed to be a simple extension of real OOP with a C syntax. Like other embedded languages, most of which are either assemblers or functional strangely enough, it has grown to include methods of getting at the machine and conecpts such as closures. If it adopted lamda calculus syntax extensions, you could use it to teach mathematical therom proving.

However you choose to view the language, as toy, irritant, the next wave, the last wave, et cetera, it is in our CompSci cirricula and it can be taught and taught well. When I went on to my second year of classes I was exposed to C++ for Data Structures and Java for a Programming Abstractions course. Data Structures became a waste of a class trying while to work with a professor who was new to the lanugage. The Programming Abstractions professor knew what was up with Java and so taught us a lot about OO design before delving into the language. I didn't get a lot of help from my time learning Haskel, wich in turn had severly limited my time working with C before moving onto C++.

For what it's worth, learning RCS, and later CVS and UML, helped with my programming more than any of the languages I in which I learned or worked. In the end, these languages proved that they are just tools. Like all tools - Craftsman, DeWALT, GNU liscenses, Sun.Java.*, there will be proponents and detractors and teachers and charlitans. You mileage may vary.

Here's to 5 years of CompSci and counting (with 1 year to go.)