That's pretty much the whole point of high frequency trading. Systems can cancel orders before they are fullfilled, so they can determine what volumes/prices people are willing to buy/sell at, without actually making any transactions.
Statistically (in the US) you are more likely to receive a head injury while walking in a city than riding a bicycle in the same city (per hour of activity). I don't think the pedestrian/cyclist speed matters much, because the force of a 1.5 ton car hitting you far outweighs the force generated by a 200 lb rider/bike.
Oh no, instead of downloading to.doc and emailing, you'll have to click share. Your customers are going to be absolutely outraged when they realize they no longer have to download anything, don't need an expensive fat client program, and can see changes to the docs in real time. Of course, you could always try.pdf instead, which has most of the same 'benefits' as.doc.
I agree, I always try to refactor commented code into self-documenting code, and I try to eliminate as many comments as possible before pushing a change. However, there are some legitimate reason for comments. Code should be commented any time it is non-obvious. Examples of non-obviousness include algorithms, performance hacks, bug work arounds, and strange business requirements.
Yes, but this data is evidence in a case, which means it has to follow chain of custody rules. They can't just through it onto a harddrive and put it on the shelf. They have to ensure the data is not tampered with to have it admissible in court, which probably means access to the drive and storage is restricted and monitored, and they probably have to hash the data and restrict and monitor access to the hash, so that it can be proved that the data is untampered.
I don't know about CS, but in many fields the MS is equivalent to the 1st 2 years in a PhD program. In the US, the 1st 2 years are graduate level classes, at the end of which you need to pass an exam before continuing on to do research and write your thesis (which will probably tak an additional 2-4 years). If you get through 2 years and realize it's not for you, you can usually just quit and get an MS instead.
Even if they they take steps to avoid exposing usernames, most sites are still vulnerable to timing attacks. Try logging in to a page repeatedly with a script. Most unprotected sites will take longer to return a response when the username is valid. when the username is not valid, the response returns immediately, while if the username is valid the system usually has to hash and compare the passwords, plus log data about login attempts.
Anyone else see the hot Motif action when JPL was showing off the first thumbnails from curiosity live on NASA TV? Pretty awesome, and brought back old memories of working with Sun workstations.
Yes, and the funny thing is that the US manufacturing sector has never really shrunk in terms of dollar output, only jobs and some market share to China. In fact, the number of manufacturing jobs worldwide, not just in the US, has been consistently declining for the past 30 years due to increased automation. We will never get more manufacturing jobs, ever, no matter what policies the government puts in place.
Re:Good programmer = good PHP code
on
The PHP Singularity
·
· Score: 4, Insightful
No, to write good PHP code you have to be both a good coder and a PHP expert, otherwise its inconsistencies and corner cases will bite you in the ass. On the other hand, a good coder can write good code in Python, Ruby,.net, and java, because those languages generally do what you expect them too, and you're not going to accidentally open a massive security flaw by having an incorrect setting in php.ini or forgetting to pass the right parameters into get_file_contents.
While it's possible, most desktop apps tend to have horribly unusable interfaces compared to their browser based counter parts. Some people attribute it to the IDE effect, where developers make apps with a similar UI to their IDE. I would say it has more to do with the inversion of the learning curve between the 2 paradigms. The HTML/css ecosystem is difficult to learn and simple layouts are more difficult than they should be, but once you know what you're doing intuitive and user friendly layouts are only a little extra work. Contrast the html/css learning curvewith typical desktop development frameworks like Swing, where simple layouts are trivial, but it's a lot of work if you want something more intuitive than a grid layout with menus. The new UI paradigms like modality and notifications emerging in the mobile space are superior to both browser and desktop, and are already having a huge influence.
Your rural customers had good enough network to use desktop programs but not browser based apps? It seems to me like a well designed browser app would transfer a similar amount of data, so I don't understand what the difference would be. Were you using old school server-side generated pages rather than a modern architecture of client-side javascript talking to an api endpoint?
If it's going to be a true app providing more functionality than content, I would strongly recommend against the old school server-side html generation approach. Instead, use a front-end webserver to serve static files and bootstrap a Javascript app. The Javascript app can then fetch data from the server using RESTful webservices and update the UI. I have extensive experience building enterprise web apps under my belt and have tried many different strategies. This is by far the best approach, as it is quicker to develop, easier to test, easier to consume your business logic with diverse clients (i.e mobile devices, desktop, Flash), and easier to expose a public api to your customers.
Depending on your needs ExtJs, Dojo, and Backbone.js are all capable front-end frameworks. ExtJS and Dojo are nice, because they are monolithic libraries that already have most of what you need, including MVC modularization, UI components, and a production deployment path. Backbone.js is nice because it gives you the bare bones tools to make an app without anything you don't need, but you will have to either add many things yourself or pull in multiple libraries, which can become a maintenance and licensing problem later on down the road. JQuery is also functional, but a large app will quickly turn to spaghetti code if you do not also include some type of MVC framework for modularizing your code.
If you use the Javascript front-end approach, there will be some tricky things you'll need to think about, such as how the back button should work (and in your specific example: timezones). It's extremely important to find quality Javascript devs, who have already experienced similar problems and know how to deal with them. Finding good Javascript devs in the current market is much more challenging than finding decent back-end devs, regardless of what back-end technology you choose.
I prefer Python for the backend with Ruby as a close second, but IMO it doesn't really matter what stack you pick for the backend. I would try to stay away from PHP, just because of technical issues, and the fact that it annoys me as a dev. Python, Ruby, Java, Groovy,.Net, and node.js are all mature, capable technologies that you will be able to find decent devs to hack on. The reality is that besides the addition of NoSQL databases and asynchronous programming models used for 'real-time' features, backend MVC development frameworks haven't changed all that much in the past 5-10 years. They all work pretty much the same way: you'll have url routers, controller classes, html templates, a model layer, possibly an ORM, and a DB api. Whichever backend you choose, one of the most important things to think about is how you want to host it. If you're going to be using AWS, Heroku, Rackspace, vps, etc,. Stacks have distinct advantages and disadvantages on certain cloud providers.
For databases I would choose Postgresql for a relational database. Well supported, great documentation, awesome feature set, open source, and easy to find devs for. For NoSQL databases, I really like MongoDB. Your project sounds like it would work well with either type of database, but remember that you don't have to be stuck with just one type of database. There are plenty of projects that use both relational and NoSQL databases for different services under the same roof.
I've tried working remotely, and without people to talk to or get distracted by I end up taking fewer breaks and working longer hours. I'm probably more productive at home, but I could never do it for an extended period of time, because I end up stressed and burnt out. I'm sure other people are different, but my recommendation is that if you're thinking about working remotely you should try it for a couple of weeks before committing.
There's more to it than that. WebOs and the phones that ran it right before they collapsed were great. Marketing and their decision to enter an exclusive deal with Sprint are what killed Palm.
I love Python , so I'm going to give you some reasons to try it out. Once I got used to whitespace based blocks, I came to prefer it over braces. It's less typing, and if you ever have to deal with spaghetti code, mistakes are easier to spot, because the code is forced to be formatted correctly.
The great things about python for both beginners and experts are that It's a true oo language, and it's very consistent. It uses prototype inheritance, is namespaced, and modules, classes, and functions are all first class objects. Operators are just syntactic sugar for method calls. All errors are expressed as exceptions. Datatypes have consistent interfaces: for example strings and lists shared the same interface because they're both sequences, and files and sockets share the same interface because they're both 'file like objects'. Unicode is a breeze. There are tons of libraries, and most are very high quality. Extending with C or C++ is easy.
Sounds like it was just a bug that didn't get caught by QC. An unexpected exception caused a page to get cached incorrectly. Perhaps the page wasn't supposed to be cached, or perhaps the cache key was calculated incorrectly.
The buggy language thing is total BS. Bugs per line is pretty constant across all languages, and lower level languages require many more lines of code than Python. You do the math.
There are plenty of domains where threads aren't very useful. For example Python is extremely popular in scientific computing and other big number crunching jobs. If you're running on a cluster or 'in the cloud' without shared memory like many modern data analysis algorithms, threads aren't very useful. Another popular domain for Python is networking code which is usually non-threaded and asynchronous in order to handle many connections smoothly (ala node.js).
Priuses are popular with wealthy individuals. People don't buy them because they save gas, they buy them because it gives them green cred, geek cred, or just because they want toys with the latest tech
I think marketing a more expensive car for this market is the right thing to do. Car companies need to get into a different mindset. It doesn't necessarily matter if your car has the best tech anymore. 1st to market and a strong track record now have a huge influence, just like in the tech device market.
In the US you can get a patent for novel genetically modified life forms. You cannot get a patent for nature un-modified life or DNA. You can't patent your personal genome or your cat's genome. If you splice your cat's night vision gene into your own genome to get awesome cat-vision, then you can patent it.
Slashdot Mirror
That's pretty much the whole point of high frequency trading. Systems can cancel orders before they are fullfilled, so they can determine what volumes/prices people are willing to buy/sell at, without actually making any transactions.
Statistically (in the US) you are more likely to receive a head injury while walking in a city than riding a bicycle in the same city (per hour of activity). I don't think the pedestrian/cyclist speed matters much, because the force of a 1.5 ton car hitting you far outweighs the force generated by a 200 lb rider/bike.
Oh no, instead of downloading to .doc and emailing, you'll have to click share. Your customers are going to be absolutely outraged when they realize they no longer have to download anything, don't need an expensive fat client program, and can see changes to the docs in real time. Of course, you could always try .pdf instead, which has most of the same 'benefits' as .doc.
Can you give an example of code that's not testable?
I agree, I always try to refactor commented code into self-documenting code, and I try to eliminate as many comments as possible before pushing a change. However, there are some legitimate reason for comments. Code should be commented any time it is non-obvious. Examples of non-obviousness include algorithms, performance hacks, bug work arounds, and strange business requirements.
Yes, but this data is evidence in a case, which means it has to follow chain of custody rules. They can't just through it onto a harddrive and put it on the shelf. They have to ensure the data is not tampered with to have it admissible in court, which probably means access to the drive and storage is restricted and monitored, and they probably have to hash the data and restrict and monitor access to the hash, so that it can be proved that the data is untampered.
I don't know about CS, but in many fields the MS is equivalent to the 1st 2 years in a PhD program. In the US, the 1st 2 years are graduate level classes, at the end of which you need to pass an exam before continuing on to do research and write your thesis (which will probably tak an additional 2-4 years). If you get through 2 years and realize it's not for you, you can usually just quit and get an MS instead.
Even if they they take steps to avoid exposing usernames, most sites are still vulnerable to timing attacks. Try logging in to a page repeatedly with a script. Most unprotected sites will take longer to return a response when the username is valid. when the username is not valid, the response returns immediately, while if the username is valid the system usually has to hash and compare the passwords, plus log data about login attempts.
Anyone else see the hot Motif action when JPL was showing off the first thumbnails from curiosity live on NASA TV? Pretty awesome, and brought back old memories of working with Sun workstations.
Yes, and the funny thing is that the US manufacturing sector has never really shrunk in terms of dollar output, only jobs and some market share to China. In fact, the number of manufacturing jobs worldwide, not just in the US, has been consistently declining for the past 30 years due to increased automation. We will never get more manufacturing jobs, ever, no matter what policies the government puts in place.
No, to write good PHP code you have to be both a good coder and a PHP expert, otherwise its inconsistencies and corner cases will bite you in the ass. On the other hand, a good coder can write good code in Python, Ruby, .net, and java, because those languages generally do what you expect them too, and you're not going to accidentally open a massive security flaw by having an incorrect setting in php.ini or forgetting to pass the right parameters into get_file_contents.
While it's possible, most desktop apps tend to have horribly unusable interfaces compared to their browser based counter parts. Some people attribute it to the IDE effect, where developers make apps with a similar UI to their IDE. I would say it has more to do with the inversion of the learning curve between the 2 paradigms. The HTML/css ecosystem is difficult to learn and simple layouts are more difficult than they should be, but once you know what you're doing intuitive and user friendly layouts are only a little extra work. Contrast the html/css learning curvewith typical desktop development frameworks like Swing, where simple layouts are trivial, but it's a lot of work if you want something more intuitive than a grid layout with menus. The new UI paradigms like modality and notifications emerging in the mobile space are superior to both browser and desktop, and are already having a huge influence.
Your rural customers had good enough network to use desktop programs but not browser based apps? It seems to me like a well designed browser app would transfer a similar amount of data, so I don't understand what the difference would be. Were you using old school server-side generated pages rather than a modern architecture of client-side javascript talking to an api endpoint?
Dammit, no line breaks. How do I edit?
If it's going to be a true app providing more functionality than content, I would strongly recommend against the old school server-side html generation approach. Instead, use a front-end webserver to serve static files and bootstrap a Javascript app. The Javascript app can then fetch data from the server using RESTful webservices and update the UI. I have extensive experience building enterprise web apps under my belt and have tried many different strategies. This is by far the best approach, as it is quicker to develop, easier to test, easier to consume your business logic with diverse clients (i.e mobile devices, desktop, Flash), and easier to expose a public api to your customers. Depending on your needs ExtJs, Dojo, and Backbone.js are all capable front-end frameworks. ExtJS and Dojo are nice, because they are monolithic libraries that already have most of what you need, including MVC modularization, UI components, and a production deployment path. Backbone.js is nice because it gives you the bare bones tools to make an app without anything you don't need, but you will have to either add many things yourself or pull in multiple libraries, which can become a maintenance and licensing problem later on down the road. JQuery is also functional, but a large app will quickly turn to spaghetti code if you do not also include some type of MVC framework for modularizing your code. If you use the Javascript front-end approach, there will be some tricky things you'll need to think about, such as how the back button should work (and in your specific example: timezones). It's extremely important to find quality Javascript devs, who have already experienced similar problems and know how to deal with them. Finding good Javascript devs in the current market is much more challenging than finding decent back-end devs, regardless of what back-end technology you choose. I prefer Python for the backend with Ruby as a close second, but IMO it doesn't really matter what stack you pick for the backend. I would try to stay away from PHP, just because of technical issues, and the fact that it annoys me as a dev. Python, Ruby, Java, Groovy, .Net, and node.js are all mature, capable technologies that you will be able to find decent devs to hack on. The reality is that besides the addition of NoSQL databases and asynchronous programming models used for 'real-time' features, backend MVC development frameworks haven't changed all that much in the past 5-10 years. They all work pretty much the same way: you'll have url routers, controller classes, html templates, a model layer, possibly an ORM, and a DB api. Whichever backend you choose, one of the most important things to think about is how you want to host it. If you're going to be using AWS, Heroku, Rackspace, vps, etc,. Stacks have distinct advantages and disadvantages on certain cloud providers.
For databases I would choose Postgresql for a relational database. Well supported, great documentation, awesome feature set, open source, and easy to find devs for. For NoSQL databases, I really like MongoDB. Your project sounds like it would work well with either type of database, but remember that you don't have to be stuck with just one type of database. There are plenty of projects that use both relational and NoSQL databases for different services under the same roof.
I've tried working remotely, and without people to talk to or get distracted by I end up taking fewer breaks and working longer hours. I'm probably more productive at home, but I could never do it for an extended period of time, because I end up stressed and burnt out. I'm sure other people are different, but my recommendation is that if you're thinking about working remotely you should try it for a couple of weeks before committing.
Not to mention most conferences these days are video recorded.
There's more to it than that. WebOs and the phones that ran it right before they collapsed were great. Marketing and their decision to enter an exclusive deal with Sprint are what killed Palm.
I love Python , so I'm going to give you some reasons to try it out. Once I got used to whitespace based blocks, I came to prefer it over braces. It's less typing, and if you ever have to deal with spaghetti code, mistakes are easier to spot, because the code is forced to be formatted correctly. The great things about python for both beginners and experts are that It's a true oo language, and it's very consistent. It uses prototype inheritance, is namespaced, and modules, classes, and functions are all first class objects. Operators are just syntactic sugar for method calls. All errors are expressed as exceptions. Datatypes have consistent interfaces: for example strings and lists shared the same interface because they're both sequences, and files and sockets share the same interface because they're both 'file like objects'. Unicode is a breeze. There are tons of libraries, and most are very high quality. Extending with C or C++ is easy.
Sounds like it was just a bug that didn't get caught by QC. An unexpected exception caused a page to get cached incorrectly. Perhaps the page wasn't supposed to be cached, or perhaps the cache key was calculated incorrectly.
The buggy language thing is total BS. Bugs per line is pretty constant across all languages, and lower level languages require many more lines of code than Python. You do the math.
There are plenty of domains where threads aren't very useful. For example Python is extremely popular in scientific computing and other big number crunching jobs. If you're running on a cluster or 'in the cloud' without shared memory like many modern data analysis algorithms, threads aren't very useful. Another popular domain for Python is networking code which is usually non-threaded and asynchronous in order to handle many connections smoothly (ala node.js).
Why not just buy an iPad or personal laptop to use?
Priuses are popular with wealthy individuals. People don't buy them because they save gas, they buy them because it gives them green cred, geek cred, or just because they want toys with the latest tech
I think marketing a more expensive car for this market is the right thing to do. Car companies need to get into a different mindset. It doesn't necessarily matter if your car has the best tech anymore. 1st to market and a strong track record now have a huge influence, just like in the tech device market.
In the US you can get a patent for novel genetically modified life forms. You cannot get a patent for nature un-modified life or DNA. You can't patent your personal genome or your cat's genome. If you splice your cat's night vision gene into your own genome to get awesome cat-vision, then you can patent it.