Let's encrypt isn't hard, assuming that you have enough control over the server that you can install Linux packages and that your server runs Linux. If either of these aren't true, Let's Encrypt is worthless.
Yes, this is one of THE MOST annoying thing about Agile proponents: it seems that every time they are told that Agile sucks, their reply is that it wasn't being done correctly. Which may be true! However, if that's the case, it means that Agile is so difficult to do correctly that it is a questionable thing to do.
I understand your point. On the other hand, when I am continually told that doing "x" will give result "y", but every time I've done "x" (or watched "x" being done) I've never seen "y" come from it, then I have to question the original "fact".
Because Windows 10 goes beyond mobile. It is phone, tablet, phablet, IoT, laptop, desktop, table, Xbox One, Microsoft Band.
Which begs the question: why bother? If Microsoft's effort here is successful, then I might be forced to do this -- but until then, it's just additional work for little gain.
If I have to make any changes to my code at all, or have to use Microsoft tools, then I'm not interested. Windows Phones aren't a big enough market or an interesting enough platform for me to bother.
(except in the terms of knowing what you really are supposed to do)
Interestingly, in each of the places I've worked where Agile was used, there was more uncertainty about what you are really supposed to do than in places without it. In two of those places, we went from the standard development process to Agile, and we went from everyone knowing what had to be done and what they need to be doing individually to nobody really being sure of anything.
Done correctly for the right kinds of projects, Agile is a good way to do things.
I've heard this claim many times, and maybe it's even true. I've just never seen it happen that way. In every project I've seen that follows a variant of Agile, the result has been that it takes longer to produce lower quality code compared to if you're using more established methodologies.
But a team with good interpersonal dynamics (also known as a functional team) doesn't need anything that a formalized Agile process brings. They're already doing those few things in Agile that are actually a good idea.
Then I have no idea what you mean by "be specific". I was plenty specific enough for this discussion. I doubt that you actually want me to dive into the technical details.
I will add a clarification about my comment about performance. If by "performance" you mean "speed", then you are (as I already said) correct that what is good depends entirely on what the app does. However, performance means a lot more than speed. It also means things like CPU cycles: an app with good performance is an app that uses the least possible CPU cycles to accomplish a task. The importance of this goes beyond speed. On mobile devices, for example, it also goes to battery life.
Any app that is written in Javascript (or any other interpreted or semi-compiled language) burns through a lot more CPU cycles than is required for the task. That is why I say that performance inevitably suffers. This is true even is you don't notice a speed difference as the user.
Now, come on, there's no need to start getting nasty here.
The two main things that are limiting are that you can't take advantage of the unique strengths of the particular device you're running on, and the performance always (and inevitably) suffers.
Whether those limitations are important depends entirely on the type of app you're writing, although I maintain that maximizing performance is always important on mobile platforms in order to maximize battery life. That said, I am completely aware that the rest of the software industry long ago decided that sacrificing performance was acceptable in exchange for reducing developer effort. Which is one of the reasons why software quality has been declining for decades now.
I've long advocated for a 'smart terminal' approach, where the 'app' is just a GUI with a set of capabilities, and all the smarts are up on the server.
As a user, what you're advocating is something I consider a dystopian nightmare.
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
Well, that's clearly a matter of opinion. I have done the same, and in my opinion, nothing beats going native (assuming you are trying to achieve the same end results, which is difficult-to-impossible, considering how limiting web apps are.)
Whenever this discussion comes up, I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web
Why would you think this? Couldn't it equally be that Slashdot is filled with experienced engineers who find it instinctively painful to write applications in a way that provides a substandard user experience compared to the other options available?
and has no vendor lock in or censorship issues like the mobile walled gardens have.
That's a separate issue, and one that doesn't apply to Android (since you aren't required to work inside any walled gardens).
I'm not talking about being usable on the mobile device. I'm talking about being usable on the desktop. Sites that are "responsive" tend to dramatically reorganize themselves based on the size of the window, so when I reduce the browser window to something small, I end up getting the "mobile" layout -- which is what I do not want to have happen. I want the site layout to stay essentially the same and get scrollbars so that I can see just the part of the content that I'm interested in. Responsive designs mess that up completely.
I wish website designers would at least provide an option to disable the responsiveness when I don't want it. That would be an acceptable compromise.
I think you missed my point. The vast majority of sites that are using "responsive design" suck directly because of it. If there are frameworks that lets websites do responsive design that doesn't suck, then they are clearly not using these frameworks. It's either that or the frameworks don't actually make doing "responsive design" easy.
The proof of the pudding, as they say, is in the eating. And the responsive design puddings are, by and large, horrible eating.
He's saying that if your visitors are primarily coming from search engines, then your site can ignore what search engines want without harm because being downranked by them won't hurt you.
??? If you get most of your traffic from search engines then you can ignore search engines and it won't matter? Say what?
That was a typo. I meant "if your visitors aren't primarily coming from search engines".
Plenty of sites get most of their visitors from regular readers rather than from search engines.
Plenty more don't.
Sites are able to choose not to use Google, by the way. It just takes a small edit to your robots.txt file to get Google to completely ignore your site.
The site discovery process is dominated by the use of Google. What site owners chose to put in their robots.txt file has nothing to do with this reality.
don't think google is a monopoly -- there are lots of other search engines who drive reasonable amounts of traffic. But they are certainly the Big Dog.
We live in completely separate universes. The stats I care about show Bing in second place behind Google with a whopping 2% of Google's traffic. Followed by Yahoo at 31% of Bings pathetic 2%.
Nonetheless, there is a three-way symbiotic relationship here. If Google pushes so hard that sites stop caring about their google rankings, then Google's relevance will fall.
I think if sites stopped caring about their Google rankings then Google's relevance would increase since people would be more likely to find what their actually interested in vs dealing with aftermath of billions locked up in efforts to p0wn google search results.
The way it fails is when Google algorithms make bad decisions based on largely irrelevant criteria.
If enough people find Google to suck more than the alternatives, the Google's relevance will fall.
This is a worse solution over making a separate mobile site, because it messes up the desktop experience. There are too many sites that, when I resize my browser to whatever the site considers "mobile size", give me the mobile layout. This is terrible, terrible behavior.
for some reason people seem to assume these decisions were made to be insidious or more infiltrating or all that jazz.
I assume that because it's the only thing that makes sense. If Google just wanted to offer single sign-on for those who like the idea, they could have made it optional rather than mandatory.
Making it mandatory strongly indicates that it was for the benefit of Google, not the users.
Basically they want you to bring your site into the 21st century.
Into their version of the 21st century. And they want to accomplish this by degrading the search results for everyone using Google from their mobile devices.
Slashdot Mirror
Let's encrypt isn't hard, assuming that you have enough control over the server that you can install Linux packages and that your server runs Linux. If either of these aren't true, Let's Encrypt is worthless.
Thanks, Mozilla, for yet another reason to stop using Firefox.
Yes, this is one of THE MOST annoying thing about Agile proponents: it seems that every time they are told that Agile sucks, their reply is that it wasn't being done correctly. Which may be true! However, if that's the case, it means that Agile is so difficult to do correctly that it is a questionable thing to do.
I understand your point. On the other hand, when I am continually told that doing "x" will give result "y", but every time I've done "x" (or watched "x" being done) I've never seen "y" come from it, then I have to question the original "fact".
I'm predicting that Microsoft remains a niche player in the mobile world, as it desktop market remains stable or very slowly dwindles.
This is my prediction as well. I've seen nothing in Microsoft's announcements that tells me otherwise.
Because Windows 10 goes beyond mobile. It is phone, tablet, phablet, IoT, laptop, desktop, table, Xbox One, Microsoft Band.
Which begs the question: why bother? If Microsoft's effort here is successful, then I might be forced to do this -- but until then, it's just additional work for little gain.
If I have to make any changes to my code at all, or have to use Microsoft tools, then I'm not interested. Windows Phones aren't a big enough market or an interesting enough platform for me to bother.
(except in the terms of knowing what you really are supposed to do)
Interestingly, in each of the places I've worked where Agile was used, there was more uncertainty about what you are really supposed to do than in places without it. In two of those places, we went from the standard development process to Agile, and we went from everyone knowing what had to be done and what they need to be doing individually to nobody really being sure of anything.
Done correctly for the right kinds of projects, Agile is a good way to do things.
I've heard this claim many times, and maybe it's even true. I've just never seen it happen that way. In every project I've seen that follows a variant of Agile, the result has been that it takes longer to produce lower quality code compared to if you're using more established methodologies.
But a team with good interpersonal dynamics (also known as a functional team) doesn't need anything that a formalized Agile process brings. They're already doing those few things in Agile that are actually a good idea.
Now IBM is going to have to put up with the pure awfulness that is Agile, too. I'm sorry, guys.
Then I have no idea what you mean by "be specific". I was plenty specific enough for this discussion. I doubt that you actually want me to dive into the technical details.
I will add a clarification about my comment about performance. If by "performance" you mean "speed", then you are (as I already said) correct that what is good depends entirely on what the app does. However, performance means a lot more than speed. It also means things like CPU cycles: an app with good performance is an app that uses the least possible CPU cycles to accomplish a task. The importance of this goes beyond speed. On mobile devices, for example, it also goes to battery life.
Any app that is written in Javascript (or any other interpreted or semi-compiled language) burns through a lot more CPU cycles than is required for the task. That is why I say that performance inevitably suffers. This is true even is you don't notice a speed difference as the user.
Now, come on, there's no need to start getting nasty here.
The two main things that are limiting are that you can't take advantage of the unique strengths of the particular device you're running on, and the performance always (and inevitably) suffers.
Whether those limitations are important depends entirely on the type of app you're writing, although I maintain that maximizing performance is always important on mobile platforms in order to maximize battery life. That said, I am completely aware that the rest of the software industry long ago decided that sacrificing performance was acceptable in exchange for reducing developer effort. Which is one of the reasons why software quality has been declining for decades now.
I've long advocated for a 'smart terminal' approach, where the 'app' is just a GUI with a set of capabilities, and all the smarts are up on the server.
As a user, what you're advocating is something I consider a dystopian nightmare.
As a developer, I totally see the appeal.
Definitely not a shitty developer experience, I have written both natives on android and mobile web apps and mobile web apps are much easier and less error-prone to write.
Well, that's clearly a matter of opinion. I have done the same, and in my opinion, nothing beats going native (assuming you are trying to achieve the same end results, which is difficult-to-impossible, considering how limiting web apps are.)
Whenever this discussion comes up, I feel like Slashdot is just filled with old crufty C++ coders who don't understand the state of the modern web
Why would you think this? Couldn't it equally be that Slashdot is filled with experienced engineers who find it instinctively painful to write applications in a way that provides a substandard user experience compared to the other options available?
and has no vendor lock in or censorship issues like the mobile walled gardens have.
That's a separate issue, and one that doesn't apply to Android (since you aren't required to work inside any walled gardens).
I'm not talking about being usable on the mobile device. I'm talking about being usable on the desktop. Sites that are "responsive" tend to dramatically reorganize themselves based on the size of the window, so when I reduce the browser window to something small, I end up getting the "mobile" layout -- which is what I do not want to have happen. I want the site layout to stay essentially the same and get scrollbars so that I can see just the part of the content that I'm interested in. Responsive designs mess that up completely.
I wish website designers would at least provide an option to disable the responsiveness when I don't want it. That would be an acceptable compromise.
I think you missed my point. The vast majority of sites that are using "responsive design" suck directly because of it. If there are frameworks that lets websites do responsive design that doesn't suck, then they are clearly not using these frameworks. It's either that or the frameworks don't actually make doing "responsive design" easy.
The proof of the pudding, as they say, is in the eating. And the responsive design puddings are, by and large, horrible eating.
There seems to be so little good news lately, that I just have to savor this for a while!
Good lord, I suck at commenting! Everything after my "that was a typo" line shouldn't be there.
He's saying that if your visitors are primarily coming from search engines, then your site can ignore what search engines want without harm because being downranked by them won't hurt you.
??? If you get most of your traffic from search engines then you can ignore search engines and it won't matter? Say what?
That was a typo. I meant "if your visitors aren't primarily coming from search engines".
Plenty of sites get most of their visitors from regular readers rather than from search engines.
Plenty more don't.
Sites are able to choose not to use Google, by the way. It just takes a small edit to your robots.txt file to get Google to completely ignore your site.
The site discovery process is dominated by the use of Google. What site owners chose to put in their robots.txt file has nothing to do with this reality.
don't think google is a monopoly -- there are lots of other search engines who drive reasonable amounts of traffic. But they are certainly the Big Dog.
We live in completely separate universes. The stats I care about show Bing in second place behind Google with a whopping 2% of Google's traffic. Followed by Yahoo at 31% of Bings pathetic 2%.
Nonetheless, there is a three-way symbiotic relationship here. If Google pushes so hard that sites stop caring about their google rankings, then Google's relevance will fall.
I think if sites stopped caring about their Google rankings then Google's relevance would increase since people would be more likely to find what their actually interested in vs dealing with aftermath of billions locked up in efforts to p0wn google search results.
The way it fails is when Google algorithms make bad decisions based on largely irrelevant criteria.
If enough people find Google to suck more than the alternatives, the Google's relevance will fall.
This I agree with.
They have also strongly suggested that mobile users have an easy method to request the desktop version of the site.
Which does nothing to address the problem of Google altering the ranking based on their estimation of how well the site works on mobile.
This is a worse solution over making a separate mobile site, because it messes up the desktop experience. There are too many sites that, when I resize my browser to whatever the site considers "mobile size", give me the mobile layout. This is terrible, terrible behavior.
there are plenty of responsive frameworks out there, and they do actually work.
If this is the case, why is it that apparently nobody is using them?
for some reason people seem to assume these decisions were made to be insidious or more infiltrating or all that jazz.
I assume that because it's the only thing that makes sense. If Google just wanted to offer single sign-on for those who like the idea, they could have made it optional rather than mandatory.
Making it mandatory strongly indicates that it was for the benefit of Google, not the users.
Basically they want you to bring your site into the 21st century.
Into their version of the 21st century. And they want to accomplish this by degrading the search results for everyone using Google from their mobile devices.