Barring performance problems like you're having, email is the best tool for this job. It's easy, everyone has the tools to send and receive already and it's easy to keep as documentation for reference.
I'd focuss on making things work while minimizing the change to user habits, since users don't like to learn new ways of doing things (as a general rule).
Obviously, if you had the budget you could throw more hardware and bandwidth at the problem and everything would be fine. Since you're asking I'm assuming this isn't an option.
Therefor you might just want to implement some policies that would limit the problems you are having. For example, limit file attachments to a certain size. If people are sending large file attachments when they could be referencing file on a local network then find a way to make them do so. If large files need shared with people outside of the organization then posting them on a website might work. Make it easy for users to do this, either through an internet or a readily available friendly IT guy (there are a few).
You will probably have better luck getting users to learn to use an existing tool a little differently rather than introduce them to an additional tool with more limitations and drawbacks than the old one. IM isn't as nice for reference as saved emails and for situations where IM is better than an email then the phone usually even better still.
If your email problems aren't addressible through one of the above described methods...well, it sucks to be you.
I think this would only help the most blatent copying. If the watermark code is embedded in the datastructures of the source code either it would be fairly easy to remove or the software would be in such a state that it would be hard to maintain and evolve. The attempt to avoid piracy would have a negative long term effect on the project.
I can still see this being useful if blatent copying of the software is the biggest problem the project faces, however I'm having trouble envisioning a scenerio where that's the case.
Online education flies in the face of thousands of years dating back to the fucking greeks where education is done in a classroom, with interaction, with a learned instructor (usually). There's give and take.
How ironic that you post to a discussion website to complain about the lack of interaction available online.
I completed my degree from RIT (well, actually I'm one library fine away from having my degree...) by taking online courses while I worked. I started my degree full-time going to 'Real' classes. From what I've seen there are better and worse courses in each, largely dependent on the professor. If you speak to a professor that teaches both in-the-flesh and online classes they will usually tell you that they interact more with the students in the online classes.
At least for me I found the online learning experience much more fruitful and efficient, but the world is full of different kinds of people. I found that the opportunity to sit around and think for as long as I needed before replying to something in a philosophy class greatly increased what I learned as opposed to how much I would have gotten out of an in-the-flesh classroom.
I am reminded of an old poem, I don't know the author:
I think I shall never see A billboard as beautiful as a tree Indeed unless the billboards fall I'll never see a tree at all
Re:Online Courses...
on
MIT Everyware
·
· Score: 2, Interesting
I recently went back to school and finished my degree at RIT taking almost all of my classes online through their distance learning program. Since I never felt much of a 'connection' with a physically present class in the first place I found this arrangment much closer to my ideal learning format than having to drive to class everyday, get there ontime, etc.
I loved that I could do the bulk of my work after mid-night (I was working during the day). The key to making the class happen is having a responsive teacher who knows how to use the tools. There were problems when teachers I knew didn't undstand how to use the software to present and organize the class, that was mayhem.
In 2 seperate occaisions professors of mine had parents get sick and then pass away during the class. This caused a great deal of turmoil in the class as it took over a week in each case before the class knew what was going on and why the professor had suddenly dissapeared. In each case though professors showed great dedication to seeing the class through, which I really appreciated. They went above and beyond what I think you might expect from someone in those situations.
One of the reasons this was looked into is (now this is from my fuzzy memory) that some languages require the use of perfect pitch, and since no one in the culture had a problem with that it's obviously not as elusive of a skill as commonly viewed in western culture. I believe the language was a chinese dialect.
You're right on. Furthermore, having perfect pitch isn't a binary thing. I've known people with varying degrees of 'perfect pitch' and learned a little from it.
One person might be able to tell you that a note is an A 440, but if they hadn't done music for a few days they're sense might shift a little and they wouldn't notice that a note they were hearing was an A 441 instead of an A 440. This is still enough of an ability to be called perfect pitch. Other people can hear even more accurately, which might be a hinderance, as orchestras do tune to different A's in different parts of the world. Japanese orchestras tend to tune sharper (A442 for example) that US orchestras (A440).
Some people only have perfect pitch for sounds they are familiar with, like a select group of instruments, others have a better developed sense and can tell you the fundemental pitch that your refridgerator is running at.
Some people don't have perfect pitch, but still get similar results be being really intimate with the sound of their instrument. I don't have perfect pitch, but if I've been practicing something sometimes it gets stuck in my head for days so well that if I hear a bass (what I play) play a certain note a couple days later I can tell it's a D, for example. It's not reliable, and my relative pitch isn't even the best, but this happens to me.
Another interesting thing is that some researchers believe in general people are born with perfect pitch and quickly loose the ability because it's not used.
Go compare the price of a gallon of milk and a gallon of gasoline. Milk is cheaper than gas. Hydrogen is (obviously) a lot more expensive than milk. Therefore, hydrogen is much more expensive than gasoline.
A problem with your argument is that software is not a physical product like soap or any of the others you list as examples.
That aside, I think that the government competing with private enterprise example you gave could happen, in fact it already does, as the government DOES fund software, both open and closed. It hasn't really put anyone out of a job, in fact, since they are paying people to develope software they are creating jobs.
It's more likely that a programmer would get a *different* programming job than loose a job due to an increase in government funding of software projects, whether open or closed.
You don't have to know how to write drivers or program to use linux, but you do have to get used to looking things up and doing your own configuring (which mostly involves editing text files).
As for the rest of your experience, part of those problems are probably due to configuration, the rest may just be the limits of existing drivers, etc. for your hardware. To do many of the things you're used to in windows on linux will generally take more upfront work and there are still many limitations for typical desktop type use. The more you learn about linux the less of a problem these things will be. You have to decide for yourself if the trade-offs are worth it in this case. Perhaps you just want to dual boot so you have a linux system to play around with and learn about but you can still spend most of your time in a windows environment that will be less frustrating for you.
I'm not a linux nut, but as a software engineer I prefer unix systems for development work, but I must admit I enjoy having a windows box as my desktop (hey, it's got emacs) that I use as a 'portal' of sorts to all the machines that I do development on. I like this for the same reasons that you have problems with linux and working this way keeps my focus on my development work as opposed to configuring linux as my ideal desktop machine.
I'm curious about what the hard part of writing this program is. I'm a competent developer and I could put together a rough demo in a few days (times 2 for standard estimate buffering).
I'm sure there are good reasons, such as they are writing their own search engine tailored to this particular need, but using existing tools this could be cobbled together in short time.
We have a server. One program writes all emails sent to a certain email address to a certain directory. This program is probably already written and open source. We have another program running on the server, this one monitoring the directory. Each email contains a query which can be run against google using their provided API making SOAP calls. The results are returned and used to create a list of URLs. Each URL is then crawled to a set depth (other more complex factors could be substituted later), written to it's own directory (or stuffed in a db), including all image files, etc. We now have a set of directories correlated to a query.
Now we just have to get the results back to the user. A third program runs through each set of directories, it will parse the HTML to update links (including images, etc.) to how they will be seen locally by the end user, strip out unneeded stuff, perhaps replace the existing images with more compressed versions (there are plenty of existing libraries to help here), and then the whole set of directories can be compressed using a standard compression scheme such as gz or zip.
There's your demo. So what's the challenging part of improving this? Perhaps making sure the user gets the search results they want? I'm used to rapid fire searching, repeatedly zeroing in on what I'm looking for. That would take days for these users, so perhaps there is an intelligent agent in the client program that prompts the user in ways that would hopefully improve their results.
Perhaps the search engine component may rank pages differently than google based on information density or the correlation of information contained in the pages crawled from the original search result (so that one is more likely to get results where many pages talk in depth about the same subject).
Perhaps they are developing their own compression technique specific to this task. Since crawled pages will probably contain the same headers, nav, etc, they may put in a custom stage where special hooks and codes to represent that before going into a general compression stage. The client program would know how to assemble this and would usually achieve better compression than using a general approach alone.
I'd like to see how what MIT is working differs from the rather rough demo I've sketched out here.
I've worked on a lot of projects where the requirements (mostly supporting business processes) change frequently. This happens because sometimes the client didn't know what they want, they didn't really understand their own business process or for their own reasons their business process has changed. In each of these situations the software must change.
The key things I keep in mind are KISS (keep it simple, stupid) and not to over-engineer. Having studied CS and engineering in school I would try and identify similar functionality and factor it out, etc. Then due to changing requirements something would change for one part of the functionality that I had factored, but not for the other. I would have to undo all the factoring I'd done. In the end it would have been simpler to have similar code in 2 places, if the patterns are similar they will be easy to read and maintain.
Now there certainly are times to really engineer a section of code, I've always known that, but I've learned when not to go overboard. There's no point in spending half a day to factor code that already works that very well may have to be undone a few weeks later. It's all about writing good-enough software because the code base is a living document, changing constantly in order to fulfill its role as a business function.
There's a lot of other good comments here discussing situations and angles that I haven't and I agree with many of them. I just want to point out that it may be benificial to not consider some things you may have previously as Q&D, but rather as SIMPLE and GOOD-ENOUGH. Of course there are exceptions, but this is a lesson that I've learned that has really helped my productivity and ability to maintain systems.
You can't beat playing chess for brain excersize. You can play it online against people or play people in person, be it friends or people at a local club. There's a wealth of books out there on the subject and you can spend your life learning about it, no matter how good you get.
Asides from that the things I enjoy are playing musical instruments, hiking and - now that I've finally graduated - reading books I want to read for fun.
Maybe it's because my first programming experiences were with Pascal, but I consider Pascal itself to be very close to pseudocode readable for those that don't know the language. A pascal implementation should be fairly easy to adapt to another language.
The novel approach here is the combination of a firewall like proxy with the balloting system and a suspicious activity monitor. The combination of these can provide a much more robust system (at the expense of complexity and more resources) than running a firewall alone.
So while examples of each of the 3 sub-systems used in this approach have a existed for a long time, the combination of them in this context is a less well know (possibly new) idea and has merrit.
The reasons are more along the lines that statistically people that use drugs are more likely to call in 'sick' or come in late. Also I believe companies can save money on insurance by drug testing.
Really it's a bunch of bull and people should be evaulated by their individual performance, but we don't live in that world.
Center of gravity will matter. Not so much how high or low it is, but how far back it is.
Consider that the track is curved. If you break the vectors down the steeper the part of the track your center of gravity is on the quicker the acceleration of your car.
If your car's center of gravity is near to the rear it will be over a slightly steeper curve than if the center of gravity is closer to the front of the car.
Not having any measurements in front of me I can't calculate what the difference is, but there will be some difference. Only the numbers will tell how significant it is compared to other factors such as friction.
Slashdot Mirror
And even if all the coders got a nasty bug and died all the source is out there waiting for the next generation to pick up where things were left off.
The OSS movement is harder to kill than cockroaches.
Barring performance problems like you're having, email is the best tool for this job. It's easy, everyone has the tools to send and receive already and it's easy to keep as documentation for reference.
I'd focuss on making things work while minimizing the change to user habits, since users don't like to learn new ways of doing things (as a general rule).
Obviously, if you had the budget you could throw more hardware and bandwidth at the problem and everything would be fine. Since you're asking I'm assuming this isn't an option.
Therefor you might just want to implement some policies that would limit the problems you are having. For example, limit file attachments to a certain size. If people are sending large file attachments when they could be referencing file on a local network then find a way to make them do so. If large files need shared with people outside of the organization then posting them on a website might work. Make it easy for users to do this, either through an internet or a readily available friendly IT guy (there are a few).
You will probably have better luck getting users to learn to use an existing tool a little differently rather than introduce them to an additional tool with more limitations and drawbacks than the old one. IM isn't as nice for reference as saved emails and for situations where IM is better than an email then the phone usually even better still.
If your email problems aren't addressible through one of the above described methods...well, it sucks to be you.
I think this would only help the most blatent copying. If the watermark code is embedded in the datastructures of the source code either it would be fairly easy to remove or the software would be in such a state that it would be hard to maintain and evolve. The attempt to avoid piracy would have a negative long term effect on the project.
I can still see this being useful if blatent copying of the software is the biggest problem the project faces, however I'm having trouble envisioning a scenerio where that's the case.
It stands for Science-Fidelity.
Obviously.
Online education flies in the face of thousands of years dating back to the fucking greeks where education is done in a classroom, with interaction, with a learned instructor (usually). There's give and take.
How ironic that you post to a discussion website to complain about the lack of interaction available online.
I completed my degree from RIT (well, actually I'm one library fine away from having my degree...) by taking online courses while I worked. I started my degree full-time going to 'Real' classes. From what I've seen there are better and worse courses in each, largely dependent on the professor. If you speak to a professor that teaches both in-the-flesh and online classes they will usually tell you that they interact more with the students in the online classes.
At least for me I found the online learning experience much more fruitful and efficient, but the world is full of different kinds of people. I found that the opportunity to sit around and think for as long as I needed before replying to something in a philosophy class greatly increased what I learned as opposed to how much I would have gotten out of an in-the-flesh classroom.
I am reminded of an old poem, I don't know the author:
I think I shall never see
A billboard as beautiful as a tree
Indeed unless the billboards fall
I'll never see a tree at all
I recently went back to school and finished my degree at RIT taking almost all of my classes online through their distance learning program. Since I never felt much of a 'connection' with a physically present class in the first place I found this arrangment much closer to my ideal learning format than having to drive to class everyday, get there ontime, etc.
I loved that I could do the bulk of my work after mid-night (I was working during the day). The key to making the class happen is having a responsive teacher who knows how to use the tools. There were problems when teachers I knew didn't undstand how to use the software to present and organize the class, that was mayhem.
In 2 seperate occaisions professors of mine had parents get sick and then pass away during the class. This caused a great deal of turmoil in the class as it took over a week in each case before the class knew what was going on and why the professor had suddenly dissapeared. In each case though professors showed great dedication to seeing the class through, which I really appreciated. They went above and beyond what I think you might expect from someone in those situations.
Perhaps, or maybe I should just put a nose around your neck and strangle you good.
Heh, I have a 'flexi-pitch' voice, I have trouble matching a played pitch, but that's my vocal chords, not my ear.
a yjune2001/html/shorts/babyperfect.htm.
The first link off google for "perfect pitch birth loss" is http://www.theuniversityhospital.com/healthlink/m
One of the reasons this was looked into is (now this is from my fuzzy memory) that some languages require the use of perfect pitch, and since no one in the culture had a problem with that it's obviously not as elusive of a skill as commonly viewed in western culture. I believe the language was a chinese dialect.
That's just sick!
:)
I belong to the 'close enough for jazz' group myself, but maybe that's just because I'm lazy and lack real talent.
You're right on. Furthermore, having perfect pitch isn't a binary thing. I've known people with varying degrees of 'perfect pitch' and learned a little from it.
One person might be able to tell you that a note is an A 440, but if they hadn't done music for a few days they're sense might shift a little and they wouldn't notice that a note they were hearing was an A 441 instead of an A 440. This is still enough of an ability to be called perfect pitch. Other people can hear even more accurately, which might be a hinderance, as orchestras do tune to different A's in different parts of the world. Japanese orchestras tend to tune sharper (A442 for example) that US orchestras (A440).
Some people only have perfect pitch for sounds they are familiar with, like a select group of instruments, others have a better developed sense and can tell you the fundemental pitch that your refridgerator is running at.
Some people don't have perfect pitch, but still get similar results be being really intimate with the sound of their instrument. I don't have perfect pitch, but if I've been practicing something sometimes it gets stuck in my head for days so well that if I hear a bass (what I play) play a certain note a couple days later I can tell it's a D, for example. It's not reliable, and my relative pitch isn't even the best, but this happens to me.
Another interesting thing is that some researchers believe in general people are born with perfect pitch and quickly loose the ability because it's not used.
Go compare the price of a gallon of milk and a gallon of gasoline. Milk is cheaper than gas. Hydrogen is (obviously) a lot more expensive than milk. Therefore, hydrogen is much more expensive than gasoline.
M < G, M < H, therefor G < H?
Surely, I cannot pick the wine in front of you.
That's amazing. I've got the same combination on my luggage!
The answer to the biased rankings problem is so obvious. Use an algorithm to generate the result set and then random sort!
A problem with your argument is that software is not a physical product like soap or any of the others you list as examples.
That aside, I think that the government competing with private enterprise example you gave could happen, in fact it already does, as the government DOES fund software, both open and closed. It hasn't really put anyone out of a job, in fact, since they are paying people to develope software they are creating jobs.
It's more likely that a programmer would get a *different* programming job than loose a job due to an increase in government funding of software projects, whether open or closed.
You don't have to know how to write drivers or program to use linux, but you do have to get used to looking things up and doing your own configuring (which mostly involves editing text files).
As for the rest of your experience, part of those problems are probably due to configuration, the rest may just be the limits of existing drivers, etc. for your hardware. To do many of the things you're used to in windows on linux will generally take more upfront work and there are still many limitations for typical desktop type use. The more you learn about linux the less of a problem these things will be. You have to decide for yourself if the trade-offs are worth it in this case. Perhaps you just want to dual boot so you have a linux system to play around with and learn about but you can still spend most of your time in a windows environment that will be less frustrating for you.
I'm not a linux nut, but as a software engineer I prefer unix systems for development work, but I must admit I enjoy having a windows box as my desktop (hey, it's got emacs) that I use as a 'portal' of sorts to all the machines that I do development on. I like this for the same reasons that you have problems with linux and working this way keeps my focus on my development work as opposed to configuring linux as my ideal desktop machine.
Bandwidth.
I'm curious about what the hard part of writing this program is. I'm a competent developer and I could put together a rough demo in a few days (times 2 for standard estimate buffering).
I'm sure there are good reasons, such as they are writing their own search engine tailored to this particular need, but using existing tools this could be cobbled together in short time.
We have a server. One program writes all emails sent to a certain email address to a certain directory. This program is probably already written and open source. We have another program running on the server, this one monitoring the directory. Each email contains a query which can be run against google using their provided API making SOAP calls. The results are returned and used to create a list of URLs. Each URL is then crawled to a set depth (other more complex factors could be substituted later), written to it's own directory (or stuffed in a db), including all image files, etc. We now have a set of directories correlated to a query.
Now we just have to get the results back to the user. A third program runs through each set of directories, it will parse the HTML to update links (including images, etc.) to how they will be seen locally by the end user, strip out unneeded stuff, perhaps replace the existing images with more compressed versions (there are plenty of existing libraries to help here), and then the whole set of directories can be compressed using a standard compression scheme such as gz or zip.
There's your demo. So what's the challenging part of improving this? Perhaps making sure the user gets the search results they want? I'm used to rapid fire searching, repeatedly zeroing in on what I'm looking for. That would take days for these users, so perhaps there is an intelligent agent in the client program that prompts the user in ways that would hopefully improve their results.
Perhaps the search engine component may rank pages differently than google based on information density or the correlation of information contained in the pages crawled from the original search result (so that one is more likely to get results where many pages talk in depth about the same subject).
Perhaps they are developing their own compression technique specific to this task. Since crawled pages will probably contain the same headers, nav, etc, they may put in a custom stage where special hooks and codes to represent that before going into a general compression stage. The client program would know how to assemble this and would usually achieve better compression than using a general approach alone.
I'd like to see how what MIT is working differs from the rather rough demo I've sketched out here.
I've worked on a lot of projects where the requirements (mostly supporting business processes) change frequently. This happens because sometimes the client didn't know what they want, they didn't really understand their own business process or for their own reasons their business process has changed. In each of these situations the software must change.
The key things I keep in mind are KISS (keep it simple, stupid) and not to over-engineer. Having studied CS and engineering in school I would try and identify similar functionality and factor it out, etc. Then due to changing requirements something would change for one part of the functionality that I had factored, but not for the other. I would have to undo all the factoring I'd done. In the end it would have been simpler to have similar code in 2 places, if the patterns are similar they will be easy to read and maintain.
Now there certainly are times to really engineer a section of code, I've always known that, but I've learned when not to go overboard. There's no point in spending half a day to factor code that already works that very well may have to be undone a few weeks later. It's all about writing good-enough software because the code base is a living document, changing constantly in order to fulfill its role as a business function.
There's a lot of other good comments here discussing situations and angles that I haven't and I agree with many of them. I just want to point out that it may be benificial to not consider some things you may have previously as Q&D, but rather as SIMPLE and GOOD-ENOUGH. Of course there are exceptions, but this is a lesson that I've learned that has really helped my productivity and ability to maintain systems.
You can't beat playing chess for brain excersize. You can play it online against people or play people in person, be it friends or people at a local club. There's a wealth of books out there on the subject and you can spend your life learning about it, no matter how good you get.
Asides from that the things I enjoy are playing musical instruments, hiking and - now that I've finally graduated - reading books I want to read for fun.
Maybe it's because my first programming experiences were with Pascal, but I consider Pascal itself to be very close to pseudocode readable for those that don't know the language. A pascal implementation should be fairly easy to adapt to another language.
The novel approach here is the combination of a firewall like proxy with the balloting system and a suspicious activity monitor. The combination of these can provide a much more robust system (at the expense of complexity and more resources) than running a firewall alone.
So while examples of each of the 3 sub-systems used in this approach have a existed for a long time, the combination of them in this context is a less well know (possibly new) idea and has merrit.
The reasons are more along the lines that statistically people that use drugs are more likely to call in 'sick' or come in late. Also I believe companies can save money on insurance by drug testing.
Really it's a bunch of bull and people should be evaulated by their individual performance, but we don't live in that world.
Center of gravity will matter. Not so much how high or low it is, but how far back it is.
Consider that the track is curved. If you break the vectors down the steeper the part of the track your center of gravity is on the quicker the acceleration of your car.
If your car's center of gravity is near to the rear it will be over a slightly steeper curve than if the center of gravity is closer to the front of the car.
Not having any measurements in front of me I can't calculate what the difference is, but there will be some difference. Only the numbers will tell how significant it is compared to other factors such as friction.
This is a physics 101 problem.
http://www.datahiveserver.com/products/servers/m1/