Heuristics like this might be interesting on a theoretical level, but they won't be anywhere near as reliable as other approaches. I don't want my phone to have its functions disabled because I'm halfway through typing a text message and I sneeze or something. Phone integration with cars is only going to increase. Link cars with phones via Bluetooth and have the cars tell the phones when they are in motion.
At that point, their best bet is to discredit you, using the same ease of spreading information. And once you are discredited, you are once again "solvable".
If me being discredited works, then I wouldn't need to be "solved". If it doesn't work, then I succeeded in my goal. Either way, I'm no longer a threat to them.
How's that working out for Julian Assange? Once you spread the information, their priority changes from containment to revenge./i>
What makes you think the way Assange is being treated is motivated by revenge? Even if you believe there is a conspiracy against him, the most likely explanation would be to stop him from continuing his work.
I'm not interested in running for the rest of my life, so my goal would be to solve the problem permanently. If the problem is that I witnessed something, then I'd get my testimony and any relevant information in my possession as widely distributed as I could. Once the information is beyond containing, stopping me will no longer solve my opponent's problem. They'll have bigger problems to worry about than me. You can distribute your materials from anywhere these days - record a video on your phone, upload it to as many websites as possible, stick it on Wikileaks, email the press...
Define "lighter". Memory use? CPU use? Disk use? Latency? These sorts of things are highly dependent upon configuration in both MySQL and PostgreSQL. How are you measuring "lighter", and is this assuming default configuration?
Who cares about a possible iPad Mini that isn't drinking the Kool-Aid already?
Pretty much everybody, because whether you choose to acknowledge it or not, Apple defined this market with the iPad. You say it yourself, all the major competitors are basically following Apple's lead. Every tablet from every competitor is compared to the iPad in reviews. The tablet market was practically non-existent before the iPad was released. It's not so much a tablet market as an iPad market with a few hangers on.
I've been using a standing desk for about a year now. I like it. With a chair, it's all too easy to be glued in place without moving a muscle for hours at a time. With a standing desk, you do tend to shift your weight around a bit from time to time. I don't tend to stand up all day. I have a stool that I sit on for about a quarter of the time, so I alternate between standing and sitting every so often. When I've been standing for a while, it feels good to change to sitting, and when I've been sitting down for a while, it feels good to change to standing. I don't get sore legs or feet. Chances are, if you get sore from standing around for a couple of hours, you could do with exercising those muscles more anyway.
It's a move in the right direction, but the way Apple are going about it is harming developers and confidence in the App Store unnecessarily.
I completely agree that sandboxing is a valuable requirement, and regardless of anybody's opinions on Apple's control over the ecosystem, they have used that control to cut out a lot of really shitty practices by software vendors, and this is another example of them using that control to push vendors in the right direction.
The problem, though, is that the entitlements on offer are half-baked. There's a lot of software that legitimately needs more entitlements, and Apple haven't been responsive in catering to these needs. It wouldn't take much to handle this properly, but Apple are being too aggressive in pushing this forward prematurely. They are dropping the ball on this one, and it has the potential to sabotage the App Store before it's fully established itself.
Android applications aren't Java applications. They are written in the Java language, but they are then compiled to run on the Dalvik VM. Even if they were Java applications, you couldn't simply drop them onto any old Java VM and have them work; they need all the runtime libraries present on Android to work.
It's a pain. It's usually the case that you don't know ahead of time what content is going to be in a scrollable part of your application. This means that there will often be no visual indication (such as half-displayed lines of text) that the user can scroll to see more content. Graphic designers have to do extra work to provide visual cues for this, and developers have to do extra work to make it work seamlessly.
You've already got a single point of failure: your email. Compromise that and you can reset the password for the majority of online accounts a person holds.
To put it bluntly: your son knows what he's talking about and you do not. He is on the right path and you are unwittingly sabotaging him.
I've been developing for the web since the 90s, and in all that time, I've never met somebody who works full-time as a web developer who does not hand-code. The "WYSIWYG" editors are a last resort for people who do not know how to code. If he wants to do this professionally and he follows your advice, he'd be turning himself into a laughing stock.
I argue with him that while handcoding abilities are essential and great there is a value in knowing and using WYSIWYG editors.
What value? You say there's value, but you don't say what you think it is. It's not getting a job - I certainly wouldn't hire a "developer" who used these. I've never needed to use them myself in almost 15 years of working as a developer. Nobody has ever asked me to use them. So where's the value?
an iOS App that helps identify potentially intrusive applications and show users what they do behind their back
Apple don't typically allow you to snoop on what other applications are doing. Applications are supposed to be sandboxed to prevent this. I would assume that there's a far more mundane reason for banning this application - that it was doing things it wasn't supposed to be doing.
Unlike other multilingual programming languages, Babylscript allows people to write programs in a mix of different languages. A programmer can take a library written in French, mix it with their own program written in Spanish, and use code snippets they found on a Chinese help forum.
I would hazard a guess and say that it's easier for a non-English speaker to learn normal JavaScript than it is for anybody to deal with this kind of nonsense.
I don't really see the advantage in this. You would be deliberately segregating yourself from the wider development community, and for what? Anglophones have to learn a lot of this stuff too. An asterisk doesn't mean multiplication to us, yet we learn that. Double ampersands don't mean "and", yet we learn that. Parentheses don't mean "do something", yet we learn that. The equals sign means "equals" in English, yet it's the assignment operator in JavaScript.
There are languages which are designed to more closely match natural language. AppleScript and Basic, for instance. There care also language which aren't very readable at all in English, such as LISP or Perl, that are still very successful. Natural language isn't really valued in the programming world for a variety of reasons. Sure, function calls might have some correspondence with English, but in the end, they are labels, not sentences, and everybody needs to learn what the labels mean precisely, even English people.
I think he meant "on the web" as in "accessible from the web"
No, he meant what he wrote. No need to twist his words.
Yes, a web page may link to a mailto: URI, but at least traditionally that would always launch an e-mail client that speaks other protocols like SMTP, POP3 and IMAP. It's just a way to hand you off to a specific spot outside the web by passing parameters, not part of the web.
Just because a web browser doesn't handle a particular protocol natively, it doesn't mean that it's not part of the web. Some web browsers support FTP, some do not. Does that mean a resource accessible through FTP is or is not part of the web depending on which browser is used to access it? Of course not.
The access scheme is by definition the highest point of flexibility. What does that mean? It means that if the whole Web develops problems which we cannot solve within the existing protocols, or if new spaces are designed which really can't be accessed through or mapped into existing spaces, then we can create a new space. We have faith that we will be able to use this flexibility point in the future, because it worked successfully for integrating the older spaces such as Gopher and FTP spaces into the Web.
The Web's protocols (including HTTP, FTP, SOAP, NNTP, and SMTP)
The web has always been more than simply "what you read over HTTP in a web browser". That's the opinion of its creator, the opinion of the organisation that manages is, and the description detailed by myriad defining documents.
What's not on it: Lots of stuff. E-mail, smartphone apps, peer-to-peer file-sharing networks, instant messaging programs, FTP, and Usenet, for example.
The web is not simply whatever is transmitted over HTTP. It's an information space, where anything addressable by URI is a leaf in the node. For instance, a telephone number is part of the web because of tel: URIs. Most of the things on his list are part of the web too - there are FTP and NNTP protocols. And in fact, some P2P networks work over HTTP anyway.
Firstly: How does the system detect imminent crashes? If this makes mistakes, it can wrest control away from the driver when unnecessary and cause a crash.
Secondly: How does the system react to imminent crashes? If this performs worse than what the driver was already doing, it can cause a crash.
The main problem with autonomous driving is the legal liability. The problems above still introduce the legal liability, yet without the major benefits from a broader system. I think the industry will simply skip over this straight to broader systems.
The OP mentioned clients - he's building apps for other people. The article you cite is about the kind of developers who only work on their own apps. Yes, it can be difficult to make money that way. But any freelance iOS developer with multiple clients can easily afford to buy a new Mac - at the going rate, it's a couple of days work for a cheap Mac.
The web 10 years ago was not fine. People were still supporting Netscape 4, which in practical terms meant that everybody was stuck with inaccessible, inefficient, inflexible table layouts that had to transmit style information for every page load. Mobile websites were practically nonexistent; where they did exist, it was a severely cut-back version. Using a single responsive design to cater to desktop and mobile uses would have been impractical even assuming today's mobile hardware. Lots of JavaScript was essentially written twice - once for Netscape and once for Internet Explorer, because the various DHTML and layout methods were different and incompatible. Netscape transcoded from CSS to JSSS internally, and lots of websites only supported Internet Explorer on Windows - a single browser on a single platform, both by the same corporation.
From a content point of view, it was still difficult to produce and manage content. Anything beyond basic stuff usually involved a very limited CMS and writing code. The "WYSIWYG" editors generated terrible, inefficient code that often only worked in one browser. Security was far worse than it is now, developers were largely clueless about even the most basic vulnerabilities, and things like the PCI standard weren't put in place yet.
These days, people are paying more and more attention to content because the technology is largely at a point where they can. Consider YouTube, Wordpress or Facebook - people generating content at phenomenal rates. Efficiency is still a prime concern due to mobile browsing, and techniques such as CSS, caching and CDNs have improved efficiency immensely. User-empowering features such as user stylesheets, user JavaScript and add-ons have grown into a thriving ecosystem, and accessibility support continues to grow.
Ten years ago was a really low point for the web. It lacked the client diversity that came before it, it was rife with incompatibilities and the inefficient designs necessary to compensate for them, and it lacked the compatibility and accessibility that mostly came afterwards. In all of the history of the web, that is probably the one point I'd least like to be stuck in.
Yeah, I visited that page. First thing I noticed was that the scrolling was all wrong. Then I tapped a menu item, the item was highlighted for about a second with no user-visible feedback beyond the selection itself, then the entire screen went white and the new content faded in. I hit the back button, the screen went white again, this time the screen didn't fade in, there was a visible redraw. I went back to the second page, tried the home menu button. Same problem, except this time, it was made worse by the menu bar popping down and then back up again. I tried the search functionality, a loading animation appeared, then there were two visible redraws. I hit the back button, an inexplicable white border appeared around the search page, then again the usual problems.
Now realise that I did this in Mobile Safari, which has better performance than in-app web views of the kind the Facebook application uses.
That kind of approach is caught in that horrible uncanny valley where it's trying not to be a website, but it can't do as well as native. Don't get me wrong, it's a good attempt, but it's simply not as good as a native approach. If you've used any native applications at all, you'll know that they do a whole lot better than this sluggish, flickery stuff.
You should remember that your phone is nearly as powerful as your desktop was only a few years ago.
And it needs to do a whole lot more than my desktop had to do a "few" (let's be honest, it's more than just a few) years ago. The web didn't stand still while mobile computing caught up.
It depends on exactly what it is you are doing, but generally speaking, native is usually noticeably faster. Even when rendering local content with a web view, you can usually see redraws and flickering where there wouldn't be any if you used native controls. You have to remember that these days, rendering a web page is actually a huge task, and this is a mobile platform, not a desktop PC. Mobile computing has come a long way in the past five years, but it's still very limited and the web is rushing along faster than ever.
Just use the protocol and the path: www/google/adwords. With the right hinting and caching, it doesn't have to be any less efficient than the current system.
Slashdot Mirror
Heuristics like this might be interesting on a theoretical level, but they won't be anywhere near as reliable as other approaches. I don't want my phone to have its functions disabled because I'm halfway through typing a text message and I sneeze or something. Phone integration with cars is only going to increase. Link cars with phones via Bluetooth and have the cars tell the phones when they are in motion.
If me being discredited works, then I wouldn't need to be "solved". If it doesn't work, then I succeeded in my goal. Either way, I'm no longer a threat to them.
What makes you think the way Assange is being treated is motivated by revenge? Even if you believe there is a conspiracy against him, the most likely explanation would be to stop him from continuing his work.
I'm not interested in running for the rest of my life, so my goal would be to solve the problem permanently. If the problem is that I witnessed something, then I'd get my testimony and any relevant information in my possession as widely distributed as I could. Once the information is beyond containing, stopping me will no longer solve my opponent's problem. They'll have bigger problems to worry about than me. You can distribute your materials from anywhere these days - record a video on your phone, upload it to as many websites as possible, stick it on Wikileaks, email the press...
Define "lighter". Memory use? CPU use? Disk use? Latency? These sorts of things are highly dependent upon configuration in both MySQL and PostgreSQL. How are you measuring "lighter", and is this assuming default configuration?
Pretty much everybody, because whether you choose to acknowledge it or not, Apple defined this market with the iPad. You say it yourself, all the major competitors are basically following Apple's lead. Every tablet from every competitor is compared to the iPad in reviews. The tablet market was practically non-existent before the iPad was released. It's not so much a tablet market as an iPad market with a few hangers on.
I've been using a standing desk for about a year now. I like it. With a chair, it's all too easy to be glued in place without moving a muscle for hours at a time. With a standing desk, you do tend to shift your weight around a bit from time to time. I don't tend to stand up all day. I have a stool that I sit on for about a quarter of the time, so I alternate between standing and sitting every so often. When I've been standing for a while, it feels good to change to sitting, and when I've been sitting down for a while, it feels good to change to standing. I don't get sore legs or feet. Chances are, if you get sore from standing around for a couple of hours, you could do with exercising those muscles more anyway.
It's not even a low percentage. Carmine, the red food colouring used in many types of food, is basically powdered insect remains.
There's also the short film Sight.
It's a move in the right direction, but the way Apple are going about it is harming developers and confidence in the App Store unnecessarily.
I completely agree that sandboxing is a valuable requirement, and regardless of anybody's opinions on Apple's control over the ecosystem, they have used that control to cut out a lot of really shitty practices by software vendors, and this is another example of them using that control to push vendors in the right direction.
The problem, though, is that the entitlements on offer are half-baked. There's a lot of software that legitimately needs more entitlements, and Apple haven't been responsive in catering to these needs. It wouldn't take much to handle this properly, but Apple are being too aggressive in pushing this forward prematurely. They are dropping the ball on this one, and it has the potential to sabotage the App Store before it's fully established itself.
Android applications aren't Java applications. They are written in the Java language, but they are then compiled to run on the Dalvik VM. Even if they were Java applications, you couldn't simply drop them onto any old Java VM and have them work; they need all the runtime libraries present on Android to work.
It's a pain. It's usually the case that you don't know ahead of time what content is going to be in a scrollable part of your application. This means that there will often be no visual indication (such as half-displayed lines of text) that the user can scroll to see more content. Graphic designers have to do extra work to provide visual cues for this, and developers have to do extra work to make it work seamlessly.
You've already got a single point of failure: your email. Compromise that and you can reset the password for the majority of online accounts a person holds.
To put it bluntly: your son knows what he's talking about and you do not. He is on the right path and you are unwittingly sabotaging him.
I've been developing for the web since the 90s, and in all that time, I've never met somebody who works full-time as a web developer who does not hand-code. The "WYSIWYG" editors are a last resort for people who do not know how to code. If he wants to do this professionally and he follows your advice, he'd be turning himself into a laughing stock.
What value? You say there's value, but you don't say what you think it is. It's not getting a job - I certainly wouldn't hire a "developer" who used these. I've never needed to use them myself in almost 15 years of working as a developer. Nobody has ever asked me to use them. So where's the value?
Apple don't typically allow you to snoop on what other applications are doing. Applications are supposed to be sandboxed to prevent this. I would assume that there's a far more mundane reason for banning this application - that it was doing things it wasn't supposed to be doing.
I would hazard a guess and say that it's easier for a non-English speaker to learn normal JavaScript than it is for anybody to deal with this kind of nonsense.
I don't really see the advantage in this. You would be deliberately segregating yourself from the wider development community, and for what? Anglophones have to learn a lot of this stuff too. An asterisk doesn't mean multiplication to us, yet we learn that. Double ampersands don't mean "and", yet we learn that. Parentheses don't mean "do something", yet we learn that. The equals sign means "equals" in English, yet it's the assignment operator in JavaScript.
There are languages which are designed to more closely match natural language. AppleScript and Basic, for instance. There care also language which aren't very readable at all in English, such as LISP or Perl, that are still very successful. Natural language isn't really valued in the programming world for a variety of reasons. Sure, function calls might have some correspondence with English, but in the end, they are labels, not sentences, and everybody needs to learn what the labels mean precisely, even English people.
No, he meant what he wrote. No need to twist his words.
Just because a web browser doesn't handle a particular protocol natively, it doesn't mean that it's not part of the web. Some web browsers support FTP, some do not. Does that mean a resource accessible through FTP is or is not part of the web depending on which browser is used to access it? Of course not.
Once more, from Tim Berners-Lee:
The web has always been more than simply "what you read over HTTP in a web browser". That's the opinion of its creator, the opinion of the organisation that manages is, and the description detailed by myriad defining documents.
The web is not simply whatever is transmitted over HTTP. It's an information space, where anything addressable by URI is a leaf in the node. For instance, a telephone number is part of the web because of tel: URIs. Most of the things on his list are part of the web too - there are FTP and NNTP protocols. And in fact, some P2P networks work over HTTP anyway.
From Tim Berners-Lee himself, writing in 1996:
Don't forget:
Sharing is stealing.
Firstly: How does the system detect imminent crashes? If this makes mistakes, it can wrest control away from the driver when unnecessary and cause a crash.
Secondly: How does the system react to imminent crashes? If this performs worse than what the driver was already doing, it can cause a crash.
The main problem with autonomous driving is the legal liability. The problems above still introduce the legal liability, yet without the major benefits from a broader system. I think the industry will simply skip over this straight to broader systems.
The OP mentioned clients - he's building apps for other people. The article you cite is about the kind of developers who only work on their own apps. Yes, it can be difficult to make money that way. But any freelance iOS developer with multiple clients can easily afford to buy a new Mac - at the going rate, it's a couple of days work for a cheap Mac.
The web 10 years ago was not fine. People were still supporting Netscape 4, which in practical terms meant that everybody was stuck with inaccessible, inefficient, inflexible table layouts that had to transmit style information for every page load. Mobile websites were practically nonexistent; where they did exist, it was a severely cut-back version. Using a single responsive design to cater to desktop and mobile uses would have been impractical even assuming today's mobile hardware. Lots of JavaScript was essentially written twice - once for Netscape and once for Internet Explorer, because the various DHTML and layout methods were different and incompatible. Netscape transcoded from CSS to JSSS internally, and lots of websites only supported Internet Explorer on Windows - a single browser on a single platform, both by the same corporation.
From a content point of view, it was still difficult to produce and manage content. Anything beyond basic stuff usually involved a very limited CMS and writing code. The "WYSIWYG" editors generated terrible, inefficient code that often only worked in one browser. Security was far worse than it is now, developers were largely clueless about even the most basic vulnerabilities, and things like the PCI standard weren't put in place yet.
These days, people are paying more and more attention to content because the technology is largely at a point where they can. Consider YouTube, Wordpress or Facebook - people generating content at phenomenal rates. Efficiency is still a prime concern due to mobile browsing, and techniques such as CSS, caching and CDNs have improved efficiency immensely. User-empowering features such as user stylesheets, user JavaScript and add-ons have grown into a thriving ecosystem, and accessibility support continues to grow.
Ten years ago was a really low point for the web. It lacked the client diversity that came before it, it was rife with incompatibilities and the inefficient designs necessary to compensate for them, and it lacked the compatibility and accessibility that mostly came afterwards. In all of the history of the web, that is probably the one point I'd least like to be stuck in.
Yeah, I visited that page. First thing I noticed was that the scrolling was all wrong. Then I tapped a menu item, the item was highlighted for about a second with no user-visible feedback beyond the selection itself, then the entire screen went white and the new content faded in. I hit the back button, the screen went white again, this time the screen didn't fade in, there was a visible redraw. I went back to the second page, tried the home menu button. Same problem, except this time, it was made worse by the menu bar popping down and then back up again. I tried the search functionality, a loading animation appeared, then there were two visible redraws. I hit the back button, an inexplicable white border appeared around the search page, then again the usual problems.
Now realise that I did this in Mobile Safari, which has better performance than in-app web views of the kind the Facebook application uses.
That kind of approach is caught in that horrible uncanny valley where it's trying not to be a website, but it can't do as well as native. Don't get me wrong, it's a good attempt, but it's simply not as good as a native approach. If you've used any native applications at all, you'll know that they do a whole lot better than this sluggish, flickery stuff.
And it needs to do a whole lot more than my desktop had to do a "few" (let's be honest, it's more than just a few) years ago. The web didn't stand still while mobile computing caught up.
It depends on exactly what it is you are doing, but generally speaking, native is usually noticeably faster. Even when rendering local content with a web view, you can usually see redraws and flickering where there wouldn't be any if you used native controls. You have to remember that these days, rendering a web page is actually a huge task, and this is a mobile platform, not a desktop PC. Mobile computing has come a long way in the past five years, but it's still very limited and the web is rushing along faster than ever.
Just use the protocol and the path: www/google/adwords. With the right hinting and caching, it doesn't have to be any less efficient than the current system.