Actually, you know what comes in handy for developing GUIs and interaction design? Cognitive Psychology. Linguisitics. Graphic Design. All taught at universities and count towards a degree in Computer Science or Cognitive science.
Need to develop an object structure or database schema for your application? At the most obvious, there's object oriented design theory. Database theory. Less obvious is analytic philosophy, such as symbolic logic, epistimology, ontology, and theory of language. They are directly applicable to knowledge representation, and help you think about abstraction, representation, and who "knows" what.
More directly to your problem, hashtable or tree for that map? Or linked list or array? If you don't know how those work, you don't know which ones are appropriate for a given task. Taught in Computer Algorithms, and can be pretty tricky to pick out the gotchas in those.
Want to write a game AI? Better have taken Artificial Intelligence and Natural Computation (neural nets, genetic algorithms, etc.) courses, or be really, really, good at predicting which algorithm to use in what case.
In all these cases, a class is usually pretty good at conferring the theory of the subject, which give you a better understanding of why and in what circumstances they work. And theory is usually hard to come by in practical books (learn to write a game in 24 hours!, learn Hibernate in 12 days!). You'll learn the how, but not the why behind the how.
If you look at industry 20 years ago it looks nothing like it does today. However, what was "theory" then (functional languages, AI, data mining, natural language processing, test driven design, parallel distributed computing) is practice today. In 20 years, the "practical" IT aspects will be completely different, but the theoretical foundations will still matter. You're going to need to learn how to keep up with practice yourself on your own as a matter of a) career maintenance and b) personal interest. From personal experience, I found it was much better for me to get started with that early. Take classes in the aspects that won't change, and teach yourself the latest and greatest. You only get a degree once, don't waste it on the flavor of the month.
Grr. I'm not denying that there's Java code out there like that, but at least get the standard system libraries right. And there's nothing requiring a long variable like that. Methods should be short enough to understand what is happening with variables even if the names are shorter.
int customerNameLength = customer.getCustomer().getFirstAndLastName().lengt h();
It's still pretty long by some standards, but I'll take readability any day. I also try to stick to 80 columns. I keep my editor at 80 columns so that I can put up things next to it like a terminal, documentation, or the actual running program.
I've been running windows and linux guests on my mac using Parallels for a year now. Linux support is definitely there, and has been from the beginning.
If you don't have an equivalant (i.e. works the same) test machine that can be used outside of production, then you're just using your test machine for production, which isn't a good position to be in no matter what development methodology you're using.
I can deny that. My wife is one of the few young people who help at the polls on election day. At the end of the day, all votes from the machines are counted up, and then all of the absentee votes are counted up. The totals aren't released without those absentee votes counted. However, absentee votes obviously don't count in exit polling.
Note: the Free Speech Zone in Boston was empty. There was no free speech zone in NYC because there were too many people who registered to protest to fit into one. The rest of Manhattan, outside of that n-block radius, (and the rest of the nation?) was the Free Speech Zone.
I'm currently using the gtk-qt engine, with Plastik. Everything looks rather nice (I kinda like Plastik, myself), and Firefox, Thunderbird, and Gimp all look great with their new clothing.
Except that Al Franken also uses footnotes, and Ann Caulter uses misleading footnotes with wrong attributions. They either don't line up (attributing the quote to the wrong person), or are taken out of context. Ann Caulter relies primarily on anger, not reason.
In the States, public libraries lend books for free. You go to your town's library, give them some proof of residency (another resident's word is often enough) and they give you a card. You can then take out as many books as you want, usually for about 3 weeks, no charge. If you want to keep them longer, you bring them back and have the loans renewed. If you forget, they charge you a nominal 10 cents per day per book. In most states, that card is good at any other public library in the state. So I can go to the state capitol library instead of my small local library, and have a huge collection at my disposal. No membership, no nothing. These libraries are usually funded partially by the towns or counties as well as by a "friends of the library" organization that conducts fundraisers. Larger libraries also have endowments, but all of them provide the service to the public at no charge.
The public library system in the US is amazing. I honestly think that it is one reason that the US has had so much of an advantage in the last century: everyone has free access to large book collections, meaning that anyone who has the inclination and interest can learn whatever they want.
Java can easily run with a larger heap maximum. Want to set it to 512 MB? Add -Xmx512m to your Java command line. It's annoying, especially for GUI apps, like you said. I hate it, but it's not a hard limit for Java, just an already running VM. The main reason that value is there is because the current garbage collector needs to know when to start working on collecting garbage. There's an experimental GC that does incremental garbage collection, but it tends to slow the machine down by about 10%.
That doesn't sound too good for your school. This stuff was discussed in my second CS class: Data Structures and Algorithms. Kinda important stuff, actually. By Junior/Senior levels, we were doing stuff with computer vision, operating systems theory, AI, computability, etc. Graph Theory was part of the third class (Formal Systems and Anlaysis), which included relational theory (write your owm RDBMS!), DFA/NDFA's, and Context Free Grammars. Most of this stuff we had to code our own implementations of, so we got an understanding of the basics. Data Structures is first-year Freshman stuff.
Actually, one problem that I have with Garrett's system is that it's so stateful (modal). I try to avoid modes in my software as much as I can, which makes Garrett's system (which was designed for web pages) of limited usefulness to me as a Swing developer. So I instead tend to create really rough mockups as a first step towards a UI.
Also, the problem that I have with flowcharts is the idea that it is a sequence of events. Garrett makes no claims about there being any sequence, only relations, links and similar structure. To me a flowchart denotes progression, but if what you're writing is an event-driven tool, then there is minimal progression - the user is the one who supplies the progress.
Sorry, but flowcharting isn't used in interaction design. Part of this is because so little of user interaction is garden-pathed anymore (at least the stuff done properly) that traditional flowcharting isn't appropriate. I refer you to Garrett IA, which is much more appropriate.
True, but flowcharts don't belong anywhere near a college-level programming class. And I'll second you on OmniGraffle. That tool rocks. I guess I'm just a little biased towards Data Flows.:-)
Of course this could be for historical purposes, but is that still done in schools? Some bad habits die hard, I guess, but I thought that flowcharting was dropped when Dijkstra declared "goto" harmful. Flowcharting has given way to pseudocode and for some UML (not that it shouldn't go the way of flowcharting, but every tool has its purpose). It's a very dangerous way of looking at coding, as it discourages abstraction, assumes a global data space (when scoping is essential to modern programming), and allows for arbitrary jumps from point to point (i.e. goto). Of course this could be all part of the lesson, but in case it isn't, I just want this student to know that there is so much more to visual software design. Of course, UML is popular these days, and for user interaction, there's the Visual Interaction Vocabulary by Jesse James Garrett. There are lessons to be learned from Flowcharting, but mostly about what to avoid.
Don't use enumerators, use Iterators. (This goes along with using the Collections framework instead of those hacks Vector, and Hashtable)
for (Iterator i=collection.iterator(); i.hasNext();) {
ObjectType o = (ObjectType)i.next();... }
This has te added benefit of being much more flexible, such as using more than one next() call per iteration, or backing up in the iteration (iterators have reverse iteration too).
It's all in the way you encode it. Mine is still more text than yours, but I can take it and move it into another document with no trouble (all the field names are preserved), I can add more fields without worrying about alignment, I can embed that data inside some sort of context, and I can transform it into arbitrary other text (including your table) using a bit of XSLT. All while still being machine and human readable. Your XML is about the most verbose way you can express that data, and it's not even valid:-) (start doc tag is dataset, closes with table).
3. What is an 'Orange Alert' anyway? What color comes next? At what tint and shade should I drop my replicated food dish and dash to my battle station? (The nation not programmed? Please.)
That which is repeatable and predictable is automatable.
Go ahead a credit me for that one. I don't remember if I got it from anywhere. The whole point of writing software is to releive people of tasks that are tedious and error-prone for people. If there are predictable, repeatable steps to produce something, then a program can be written to perform those steps. The worst term I've heard for the act of actually writing software is "software construction." Ugh. Compilers and project tools construct or, as most of you are familiar with it, build software. Does an author construct a book? No, the printer does.
What we do as developers is to design software. The design spec is the source code itself. We just have the privilege of having tools that construct from that design specification directly.
Architects (real ones, not the ones in software) will actually work on many levels in a building, not just the highest levels. There's the lead architect that figures out what the main uses of the building will be, and comes up with a general vision of how that building will work. Then, if he's lucky and has other architects working for him, he enlists their help in fleshing out the details, and designs the building down to the last sink faucet. Doesn't this sound familiar?
At this point, software and building engineering diverge. It's impossible for a architect to build functional experimental copies of their buildings, so they settle for models. They will design and build over and over (like how we write and compile over and over) until they get what they like. And then they hand it off to the construction workers, who are usually supervised by the architect during construction, because details usually crop up then.
Does anyone see the parallels between the two? We, the software engineers, are the architects. The build tools are our construction workers and model-makers. We are all designers, just at different levels, and don't let anyone try to equate you with a construction worker. You are a skilled professional whose insights and knowledge are useful to the outcome of software development.
The mere fact that they refer to software development as "Software Construction" can tell you something about how much software the author has probably "constructed". Construction is the application of repeatable processes (or, construction: Something fashioned or devised systematically).
As we all should know, repeatable processes are automatable processes. Software construction is the build method (make, install, etc). Writing the software is more akin to how a building architect designs buildings. They also automate repeatable processes, such as generating bills of materials from autocad drawings. Software development is design, even at the lowest levels, and the folks at the PMI and the SEI should remember that.
Slashdot Mirror
I use it for any reasonably sized project. It has great support for tracking time (or not), iterations, defects, and backlogs.
Actually, you know what comes in handy for developing GUIs and interaction design? Cognitive Psychology. Linguisitics. Graphic Design. All taught at universities and count towards a degree in Computer Science or Cognitive science.
Need to develop an object structure or database schema for your application? At the most obvious, there's object oriented design theory. Database theory. Less obvious is analytic philosophy, such as symbolic logic, epistimology, ontology, and theory of language. They are directly applicable to knowledge representation, and help you think about abstraction, representation, and who "knows" what.
More directly to your problem, hashtable or tree for that map? Or linked list or array? If you don't know how those work, you don't know which ones are appropriate for a given task. Taught in Computer Algorithms, and can be pretty tricky to pick out the gotchas in those.
Want to write a game AI? Better have taken Artificial Intelligence and Natural Computation (neural nets, genetic algorithms, etc.) courses, or be really, really, good at predicting which algorithm to use in what case.
In all these cases, a class is usually pretty good at conferring the theory of the subject, which give you a better understanding of why and in what circumstances they work. And theory is usually hard to come by in practical books (learn to write a game in 24 hours!, learn Hibernate in 12 days!). You'll learn the how, but not the why behind the how.
If you look at industry 20 years ago it looks nothing like it does today. However, what was "theory" then (functional languages, AI, data mining, natural language processing, test driven design, parallel distributed computing) is practice today. In 20 years, the "practical" IT aspects will be completely different, but the theoretical foundations will still matter. You're going to need to learn how to keep up with practice yourself on your own as a matter of a) career maintenance and b) personal interest. From personal experience, I found it was much better for me to get started with that early. Take classes in the aspects that won't change, and teach yourself the latest and greatest. You only get a degree once, don't waste it on the flavor of the month.
Oh for heaven's sake, that's not idiomatic python. This is equivalent:
[print i for i in range(30, 0, 1)]
Grr. I'm not denying that there's Java code out there like that, but at least get the standard system libraries right. And there's nothing requiring a long variable like that. Methods should be short enough to understand what is happening with variables even if the names are shorter.
It's still pretty long by some standards, but I'll take readability any day. I also try to stick to 80 columns. I keep my editor at 80 columns so that I can put up things next to it like a terminal, documentation, or the actual running program.
I've been running windows and linux guests on my mac using Parallels for a year now. Linux support is definitely there, and has been from the beginning.
If you don't have an equivalant (i.e. works the same) test machine that can be used outside of production, then you're just using your test machine for production, which isn't a good position to be in no matter what development methodology you're using.
I can deny that. My wife is one of the few young people who help at the polls on election day. At the end of the day, all votes from the machines are counted up, and then all of the absentee votes are counted up. The totals aren't released without those absentee votes counted. However, absentee votes obviously don't count in exit polling.
Note: the Free Speech Zone in Boston was empty. There was no free speech zone in NYC because there were too many people who registered to protest to fit into one. The rest of Manhattan, outside of that n-block radius, (and the rest of the nation?) was the Free Speech Zone.
I'm currently using the gtk-qt engine, with Plastik. Everything looks rather nice (I kinda like Plastik, myself), and Firefox, Thunderbird, and Gimp all look great with their new clothing.
Except that Al Franken also uses footnotes, and Ann Caulter uses misleading footnotes with wrong attributions. They either don't line up (attributing the quote to the wrong person), or are taken out of context. Ann Caulter relies primarily on anger, not reason.
In the States, public libraries lend books for free. You go to your town's library, give them some proof of residency (another resident's word is often enough) and they give you a card. You can then take out as many books as you want, usually for about 3 weeks, no charge. If you want to keep them longer, you bring them back and have the loans renewed. If you forget, they charge you a nominal 10 cents per day per book. In most states, that card is good at any other public library in the state. So I can go to the state capitol library instead of my small local library, and have a huge collection at my disposal. No membership, no nothing. These libraries are usually funded partially by the towns or counties as well as by a "friends of the library" organization that conducts fundraisers. Larger libraries also have endowments, but all of them provide the service to the public at no charge.
The public library system in the US is amazing. I honestly think that it is one reason that the US has had so much of an advantage in the last century: everyone has free access to large book collections, meaning that anyone who has the inclination and interest can learn whatever they want.
Java can easily run with a larger heap maximum. Want to set it to 512 MB? Add -Xmx512m to your Java command line. It's annoying, especially for GUI apps, like you said. I hate it, but it's not a hard limit for Java, just an already running VM. The main reason that value is there is because the current garbage collector needs to know when to start working on collecting garbage. There's an experimental GC that does incremental garbage collection, but it tends to slow the machine down by about 10%.
That doesn't sound too good for your school. This stuff was discussed in my second CS class: Data Structures and Algorithms. Kinda important stuff, actually. By Junior/Senior levels, we were doing stuff with computer vision, operating systems theory, AI, computability, etc. Graph Theory was part of the third class (Formal Systems and Anlaysis), which included relational theory (write your owm RDBMS!), DFA/NDFA's, and Context Free Grammars. Most of this stuff we had to code our own implementations of, so we got an understanding of the basics. Data Structures is first-year Freshman stuff.
Actually, one problem that I have with Garrett's system is that it's so stateful (modal). I try to avoid modes in my software as much as I can, which makes Garrett's system (which was designed for web pages) of limited usefulness to me as a Swing developer. So I instead tend to create really rough mockups as a first step towards a UI.
Also, the problem that I have with flowcharts is the idea that it is a sequence of events. Garrett makes no claims about there being any sequence, only relations, links and similar structure. To me a flowchart denotes progression, but if what you're writing is an event-driven tool, then there is minimal progression - the user is the one who supplies the progress.
Sorry, but flowcharting isn't used in interaction design. Part of this is because so little of user interaction is garden-pathed anymore (at least the stuff done properly) that traditional flowcharting isn't appropriate. I refer you to Garrett IA, which is much more appropriate.
Xerox, that's who. They just don't bother to tell anyone that they do.
FYI, that was not Celeborn, but Haldir, the guy that they run into first in Lothlorien. Celeborn did not leave Lothlorien.
True, but flowcharts don't belong anywhere near a college-level programming class. And I'll second you on OmniGraffle. That tool rocks. I guess I'm just a little biased towards Data Flows. :-)
Of course this could be for historical purposes, but is that still done in schools? Some bad habits die hard, I guess, but I thought that flowcharting was dropped when Dijkstra declared "goto" harmful. Flowcharting has given way to pseudocode and for some UML (not that it shouldn't go the way of flowcharting, but every tool has its purpose). It's a very dangerous way of looking at coding, as it discourages abstraction, assumes a global data space (when scoping is essential to modern programming), and allows for arbitrary jumps from point to point (i.e. goto). Of course this could be all part of the lesson, but in case it isn't, I just want this student to know that there is so much more to visual software design. Of course, UML is popular these days, and for user interaction, there's the Visual Interaction Vocabulary by Jesse James Garrett. There are lessons to be learned from Flowcharting, but mostly about what to avoid.
Don't use enumerators, use Iterators. (This goes along with using the Collections framework instead of those hacks Vector, and Hashtable)
...
for (Iterator i=collection.iterator(); i.hasNext();) {
ObjectType o = (ObjectType)i.next();
}
This has te added benefit of being much more flexible, such as using more than one next() call per iteration, or backing up in the iteration (iterators have reverse iteration too).
Of course, you can also encode it this way:
:-) (start doc tag is dataset, closes with table).
<data>
<datum day="1" sales="32"/>
<datum day="2" sales="23"/>
<datum day="3" sales="22"/>
</data>
It's all in the way you encode it. Mine is still more text than yours, but I can take it and move it into another document with no trouble (all the field names are preserved), I can add more fields without worrying about alignment, I can embed that data inside some sort of context, and I can transform it into arbitrary other text (including your table) using a bit of XSLT. All while still being machine and human readable. Your XML is about the most verbose way you can express that data, and it's not even valid
3. What is an 'Orange Alert' anyway? What color comes next? At what tint and shade should I drop my replicated food dish and dash to my battle station? (The nation not programmed? Please.)
Red.
First Axiom of software engineering:
That which is repeatable and predictable is automatable.
Go ahead a credit me for that one. I don't remember if I got it from anywhere. The whole point of writing software is to releive people of tasks that are tedious and error-prone for people. If there are predictable, repeatable steps to produce something, then a program can be written to perform those steps. The worst term I've heard for the act of actually writing software is "software construction." Ugh. Compilers and project tools construct or, as most of you are familiar with it, build software. Does an author construct a book? No, the printer does.
What we do as developers is to design software. The design spec is the source code itself. We just have the privilege of having tools that construct from that design specification directly.
Architects (real ones, not the ones in software) will actually work on many levels in a building, not just the highest levels. There's the lead architect that figures out what the main uses of the building will be, and comes up with a general vision of how that building will work. Then, if he's lucky and has other architects working for him, he enlists their help in fleshing out the details, and designs the building down to the last sink faucet. Doesn't this sound familiar?
At this point, software and building engineering diverge. It's impossible for a architect to build functional experimental copies of their buildings, so they settle for models. They will design and build over and over (like how we write and compile over and over) until they get what they like. And then they hand it off to the construction workers, who are usually supervised by the architect during construction, because details usually crop up then.
Does anyone see the parallels between the two? We, the software engineers, are the architects. The build tools are our construction workers and model-makers. We are all designers, just at different levels, and don't let anyone try to equate you with a construction worker. You are a skilled professional whose insights and knowledge are useful to the outcome of software development.
The mere fact that they refer to software development as "Software Construction" can tell you something about how much software the author has probably "constructed". Construction is the application of repeatable processes (or, construction: Something fashioned or devised systematically).
As we all should know, repeatable processes are automatable processes. Software construction is the build method (make, install, etc). Writing the software is more akin to how a building architect designs buildings. They also automate repeatable processes, such as generating bills of materials from autocad drawings. Software development is design, even at the lowest levels, and the folks at the PMI and the SEI should remember that.