Err, updating the DOM and making updates to small parts of the page as a result of Ajax calls within a front-end Javascript application is the right way to create modern web apps.
What you are advocating is the full page reload, which is a massive horror for many websites. The only use case for full page reload for trivial content updates these days is to serve another bundle of ads around the next bit of content, and single-article based websites where the content is most of the page (e.g., a news site where you are clicking between stories via category links and indexes of articles).
Seriously, many modern websites are a set of single-page applications (and maybe static pages). The only page reloads should be switching between these applications. [Page resources (JS, images, etc) should ideally be stored in a CDN if you can afford that.].
I think that Javascript devs need to learn more about creating a build process to minify and crush the JS dependencies into a single file, rather than which new framework to use for each new project they start.
If your build process takes your dependencies (from npm, for example) and then concatenates them, and minifies them into a single dependency, that saves bandwidth, http calls, and time. If it can do dead code analysis too, to remove those unused functions, then great.
From reading comments, etc, there seems to be an argument into splitting the Ajax convenience methods of jQuery out from the rest, as lots of developers use the former, but you don't need the other niceties such as the highly abstract and overhead inducing $('thing') notation. Perhaps the jQuery 3 work will go some way to fixing this anyway, as it will be far smaller in the non-compat option.
There is always the option that the news outlets have confused final asset value with construction cost.
I.e., the properties will be worth $900k each on average, once built, but the build cost is likely to be a lot lot lower.
This would seem far more reasonable for 2 and 3 bedroom apartments in a low-rise housing block, however high quality the construction is.
And assuming a more reasonable $1000 a month rent, or even $1500 a month, the financials start to make more sense if the building cost is closer to $50m than $200m.
Well, they re-use the same wafer 50-100 times, but I presume the additional processing steps add some additional per-re-use cost.
It's still $5 versus $50, but given that wafer processing itself can cost $5000 to $10000 per wafer, the wafer cost is now insignificant - especially if GaAS processing is cheaper in any way than silicon wafer processing.
I don't understand how anything is easier that hitting ctrl-k for as many lines as you want to cut, and then ctrl-u to paste them all back where you want them.
In this case there is no legacy software advantage for x86, and a lot of cost disadvantage. Intel are subsidising their products in the mobile area massively but that can't last forever.
In addition, some manufacturers are doing their own chips now, and will not see any benefit to losing control of design to Intel in this area.
The Atom core is not great either in terms of performance - an A57 core should be more powerful, and Samsung have got their 14nm process working so that advantage for Intel is not as clear-cut as it once was.
The X3 line is very weak, and will be competing against $5 to $10 SoCs from MediaTek, AllWinner, etc. This market is very price sensitive, and battery life is also important.
The X5 and X7 look more capable, it will be interesting to see how they compare against the competitor SoCs using A57 cores. The 14nm process will also help with the battery life significantly.
Double developer estimates then add some. Indeed, don't use days as a timeunit, just vague (fibonacci) numbers. If task includes the words "timezones", "character sets" or "dependency on another team" then triple... no quadruple the estimate. And then consider unit tests, component tests and regression tests.
Oddly enough some things that a manager might look at and think "oh, that'll take loads of time" due to their lack of experience (for example, service should return JSON instead of XML) actually can turn out to be quite quick (as simple as configuring a different content negotiator / resolver on your project). OTOH the developer will probably have to redo all the component tests as well.
I wrote one last week in a single line of BASIC running on a 4MHz Z80 system. Admittedly the level size is only 80x24, and it is more random than procedural (i.e., rooms can be left isolated), but that's the nature of trying to fit that into a single line of code (monster placement and gold placement take up another line).
It takes a few seconds to complete - mainly due to it being interpreted BASIC on a 4MHz Amstrad CPC.
I figure that most "dungeon generating algorithms" are quite unrealistic anyway. If you are going to build a dungeon, you're going to start somewhere, and excavate from there in a fairly compact manner (dwarf fortress/dungeon keeper style), not subdivide a massive open space, or make long tunnels into very isolated rooms (although in mines that could be viable). A realistic dungeon would also probably be quite boring to play.
As long as they can be uninstalled, great. If they're always installed then boo.
I've got a long term investment in the Google infrastructure, for better or worse. I don't want to be directed to use a different infrastructure (OneDrive, etc), and I don't want that cluttering up my phone. Luckily I expect it is easily fixed this time round via installing the correct apps from the Play store, but what about the future?
Coming from a Java background, I have found it very refreshing to start coding Clojure (which is a lisp family language that runs on the JVM).
It does appear to me that it becomes possible to write extremely compact code in Clojure compared to the equivalent Java code.
Also, the language really encourages you to just deal with the built in "primitive" collections (obviously behind the scenes they aren't primitive, but at the syntax/function level they are) - sets, maps, vectors, lists, etc for your data structures and passing data around. Java, even with Apache/Google collections help, is often a load of collection herding, shuffling and copying, which comes for free with Clojure (and will become a lot more concise with Java 8's Lambdas too).
Modern programming practices (separation of concerns, patterns, etc) also means that code often has a lot of the same boilerplate structure around it, with a little functionality in the middle. The benefit is, of course, maintainability and clarity.
To join a startup, you need to know several things you need to know in addition to the usual job stuff - how much finding does the company have (i.e., how long will it last, who is backing it, etc), will I get equity, and how much (usually in exchange for a lower salary because the funding isn't infinite), and how the team is structured.
Don't join a startup that wants you to earn less than elsewhere if they are looking at getting fun rooms, nice desks, top notch offices, etc. Join a startup that can offer you other benefits that other companies can't - working from home (save on commuting costs and time), better/flexible work hours, and so on.
The startup should offer a sizeable portion of the company as equity amongst the team. I don't know what the going rates are, but if n% of the company was given to the initial team then you would be wanting to look at n/10% for a senior dev, n/30% for a junior dev. This would drop as time passes (hires become less 'foundery' - so don't join a startup that's past the initial equity handouts unless they give even more away (and this is worrying in itself). If it's old enough to get more funding, it's not a startup and you should expect standard job benefits.
And, of course, the whole point of equity is to make a real gesture regarding the company being "your startup", beyond words. The vision is important and needs to be sold, but it means nothing without actions. Sadly I think this guy wants the benefits, and the long hours, and the low wages, without any such actions.
The new BCM2836 SoC is more or less the old BCM2835 with the ARMv6 core cut out and a v7 quad core dropped in it’s place. However there are some other minor changes can you talk about those?
There aren’t any changes to the USB subsystem, but the power system has received a tweak. 2835 has an on-board SMPS: this wasn’t large enough to supply the current needed by the quad Cortex complex, so it was removed, and Pi 2 uses an external SMPS chip. Also, as the Cortex complex has its own 512KB L2 cache, we no longer use the 128KB system L2 — ARM traffic goes directly to SDRAM instead.
And even if not, hopefully the faster and quad-core CPU will be able to respond in a more timely manner? As they would have had to do a new layout for the SoC, I hope it was another aspect that was fixed in the redesign.
But yes, ARMv8 is a significant clean up on old ARM cruft (usually exposing too much of the underlying hardware in the ISA, or design decisions that in the long term weren't as useful as they seemed at the time (like a 4-bit predication field in the ISA)).
It's just that there aren't any $5 ARMv8 SoCs available right now. I'm sure in a year or two they will appear with the A53. Right now, 4 A7s is a massive step up.
Slashdot Mirror
Err, updating the DOM and making updates to small parts of the page as a result of Ajax calls within a front-end Javascript application is the right way to create modern web apps.
What you are advocating is the full page reload, which is a massive horror for many websites. The only use case for full page reload for trivial content updates these days is to serve another bundle of ads around the next bit of content, and single-article based websites where the content is most of the page (e.g., a news site where you are clicking between stories via category links and indexes of articles).
Seriously, many modern websites are a set of single-page applications (and maybe static pages). The only page reloads should be switching between these applications. [Page resources (JS, images, etc) should ideally be stored in a CDN if you can afford that.].
I think that Javascript devs need to learn more about creating a build process to minify and crush the JS dependencies into a single file, rather than which new framework to use for each new project they start.
If your build process takes your dependencies (from npm, for example) and then concatenates them, and minifies them into a single dependency, that saves bandwidth, http calls, and time. If it can do dead code analysis too, to remove those unused functions, then great.
From reading comments, etc, there seems to be an argument into splitting the Ajax convenience methods of jQuery out from the rest, as lots of developers use the former, but you don't need the other niceties such as the highly abstract and overhead inducing $('thing') notation. Perhaps the jQuery 3 work will go some way to fixing this anyway, as it will be far smaller in the non-compat option.
There is always the option that the news outlets have confused final asset value with construction cost.
I.e., the properties will be worth $900k each on average, once built, but the build cost is likely to be a lot lot lower.
This would seem far more reasonable for 2 and 3 bedroom apartments in a low-rise housing block, however high quality the construction is.
And assuming a more reasonable $1000 a month rent, or even $1500 a month, the financials start to make more sense if the building cost is closer to $50m than $200m.
And don't forget that before that, from the 1860s in fact, there was a pneumatic parcel delivery railway between Euston and major depots.
http://www.londonreconnections...
Why is someone taking a laptop into an interview?
Well, they re-use the same wafer 50-100 times, but I presume the additional processing steps add some additional per-re-use cost.
It's still $5 versus $50, but given that wafer processing itself can cost $5000 to $10000 per wafer, the wafer cost is now insignificant - especially if GaAS processing is cheaper in any way than silicon wafer processing.
I don't understand how anything is easier that hitting ctrl-k for as many lines as you want to cut, and then ctrl-u to paste them all back where you want them.
And in addition has a clear help panel within the editor that helps you to learn the keyboard shortcuts as you use the tool.
nano is great, and I've used it for many years, and before that as pico when it was part of pine (again, one of the better email clients).
Nano already supports syntax highlighting, this just makes it more flexible (presumably).
You'll need to set up your .nanorc file to enable it.
For example, to enable perl highlighting:
include /usr/share/nano/perl.nanorc
In this case there is no legacy software advantage for x86, and a lot of cost disadvantage. Intel are subsidising their products in the mobile area massively but that can't last forever.
In addition, some manufacturers are doing their own chips now, and will not see any benefit to losing control of design to Intel in this area.
The Atom core is not great either in terms of performance - an A57 core should be more powerful, and Samsung have got their 14nm process working so that advantage for Intel is not as clear-cut as it once was.
The X3 line is very weak, and will be competing against $5 to $10 SoCs from MediaTek, AllWinner, etc. This market is very price sensitive, and battery life is also important.
The X5 and X7 look more capable, it will be interesting to see how they compare against the competitor SoCs using A57 cores. The 14nm process will also help with the battery life significantly.
Simple guide for managers:
Double developer estimates then add some. Indeed, don't use days as a timeunit, just vague (fibonacci) numbers. ... no quadruple the estimate.
If task includes the words "timezones", "character sets" or "dependency on another team" then triple
And then consider unit tests, component tests and regression tests.
Oddly enough some things that a manager might look at and think "oh, that'll take loads of time" due to their lack of experience (for example, service should return JSON instead of XML) actually can turn out to be quite quick (as simple as configuring a different content negotiator / resolver on your project). OTOH the developer will probably have to redo all the component tests as well.
Sadly for the MBAs, it will turn out that the Programming AI requires twice as many administrators and coders to maintain as the coders it replaced.
Yet this will be seen as a good thing by the business, in a fit of self-denial.
I wrote one last week in a single line of BASIC running on a 4MHz Z80 system. Admittedly the level size is only 80x24, and it is more random than procedural (i.e., rooms can be left isolated), but that's the nature of trying to fit that into a single line of code (monster placement and gold placement take up another line).
It takes a few seconds to complete - mainly due to it being interpreted BASIC on a 4MHz Amstrad CPC.
I figure that most "dungeon generating algorithms" are quite unrealistic anyway. If you are going to build a dungeon, you're going to start somewhere, and excavate from there in a fairly compact manner (dwarf fortress/dungeon keeper style), not subdivide a massive open space, or make long tunnels into very isolated rooms (although in mines that could be viable). A realistic dungeon would also probably be quite boring to play.
As long as they can be uninstalled, great. If they're always installed then boo.
I've got a long term investment in the Google infrastructure, for better or worse. I don't want to be directed to use a different infrastructure (OneDrive, etc), and I don't want that cluttering up my phone. Luckily I expect it is easily fixed this time round via installing the correct apps from the Play store, but what about the future?
Some major money must have passed hands. Shame.
In the post you hurried to reply to:
In this case, multiple return statements would make the code simpler, not harder to understand.
Coming from a Java background, I have found it very refreshing to start coding Clojure (which is a lisp family language that runs on the JVM).
It does appear to me that it becomes possible to write extremely compact code in Clojure compared to the equivalent Java code.
Also, the language really encourages you to just deal with the built in "primitive" collections (obviously behind the scenes they aren't primitive, but at the syntax/function level they are) - sets, maps, vectors, lists, etc for your data structures and passing data around. Java, even with Apache/Google collections help, is often a load of collection herding, shuffling and copying, which comes for free with Clojure (and will become a lot more concise with Java 8's Lambdas too).
Modern programming practices (separation of concerns, patterns, etc) also means that code often has a lot of the same boilerplate structure around it, with a little functionality in the middle. The benefit is, of course, maintainability and clarity.
Yes, this is totally a problem. Also people writing their pin on their card...
Exactly.
To join a startup, you need to know several things you need to know in addition to the usual job stuff - how much finding does the company have (i.e., how long will it last, who is backing it, etc), will I get equity, and how much (usually in exchange for a lower salary because the funding isn't infinite), and how the team is structured.
Don't join a startup that wants you to earn less than elsewhere if they are looking at getting fun rooms, nice desks, top notch offices, etc. Join a startup that can offer you other benefits that other companies can't - working from home (save on commuting costs and time), better/flexible work hours, and so on.
The startup should offer a sizeable portion of the company as equity amongst the team. I don't know what the going rates are, but if n% of the company was given to the initial team then you would be wanting to look at n/10% for a senior dev, n/30% for a junior dev. This would drop as time passes (hires become less 'foundery' - so don't join a startup that's past the initial equity handouts unless they give even more away (and this is worrying in itself). If it's old enough to get more funding, it's not a startup and you should expect standard job benefits.
And, of course, the whole point of equity is to make a real gesture regarding the company being "your startup", beyond words. The vision is important and needs to be sold, but it means nothing without actions. Sadly I think this guy wants the benefits, and the long hours, and the low wages, without any such actions.
Found this...
http://makezine.com/2015/02/02...
The new BCM2836 SoC is more or less the old BCM2835 with the ARMv6 core cut out and a v7 quad core dropped in it’s place. However there are some other minor changes can you talk about those?
There aren’t any changes to the USB subsystem, but the power system has received a tweak. 2835 has an on-board SMPS: this wasn’t large enough to supply the current needed by the quad Cortex complex, so it was removed, and Pi 2 uses an external SMPS chip. Also, as the Cortex complex has its own 512KB L2 cache, we no longer use the 128KB system L2 — ARM traffic goes directly to SDRAM instead.
And even if not, hopefully the faster and quad-core CPU will be able to respond in a more timely manner?
As they would have had to do a new layout for the SoC, I hope it was another aspect that was fixed in the redesign.
The ARM Cortex A7's in the new Pi have Neon.
But yes, ARMv8 is a significant clean up on old ARM cruft (usually exposing too much of the underlying hardware in the ISA, or design decisions that in the long term weren't as useful as they seemed at the time (like a 4-bit predication field in the ISA)).
It's just that there aren't any $5 ARMv8 SoCs available right now. I'm sure in a year or two they will appear with the A53. Right now, 4 A7s is a massive step up.
What happened to VC5?
Yeah, I was expecting either the Model C, or the Master myself.
I hope that means the Master is still to come. Probably in 2017 as rumoured before. This is more of a "pin compatible SoC upgrade" path.
I doubt it fixes the USB issues, although maybe the additional CPU resources will improve overall USB2 performance to meet the theoretical capability.
I think other boards are better for NAS usage.