I've seen occasional questions about IFTTT security issues (link, link, link), but nothing that isn't theoretical or speculative. Seems like there are a lot of avenues for compromising your network security and privacy. I'd love to see some hard facts about IFTTT security.
WARNING: If you're "still" using a computer that's more than 2 years old because its good enough, this post may male you feel like you made the right decision.
Sad? No, this is sad. I would love to buy a new Apple (I need a laptop, and I need to stick with Apple because of various constraints). Unfortunately, they won't sell me a new one that's much better than my "sad" old one.
I started looking for a replacement for my 2012 MacBook Pro a few months ago, fully expecting to buy myself a performance boost. I couldn't believe that Apple simply doesn't make a laptop that's significantly faster than my four year old computer.
Wow. It's four years later and I still can't buy a significant performance boost from Apple. The best I can do is an almost unnoticeable bump in speed.
Maybe more people would stop using "sad" old computers if Apple gave them a compelling reason to upgrade.
Annoying? Only like someone who never had a boot sector virus wipe out half their files because it detected it was the 26th of the month would dismiss DOS viruses as "anoying". Or, worse, someone who never had to work on a support desk when that happened.
Or someone who's only lived in a time when all computers are networked, so backing up a hard drive doesn't involve swapping 3.5" (or 5.25"!!) floppies in and out of your machine for half an hour, or waiting two hours for your tape backup to finish.
I think git can meet all of your needs, and personally I love it. - It's a free, well-established, and well-documented open source project. - There are plenty of GUIs. - For inexperienced developers, there are tutorials like this one. - Here's decent guide to getting password-less authentication via ssh working on Windows to connect to a server running locally on a Windows box (as long as it's running OpenSSH, maybe via cygwin). - You can use Git hooks to do notifications, run syntax checks, etc.
For those who don't know, COCOMO is an algorithm that was developed in 1981 by Barry Boehm for estimating the cost of building software (typically in person-hours). The numbers in the article were generated by the basic COCOMO calculation in David Wheeler's free SLOCCount toolset.
One drawback is that SLOCCount uses the basic COCOMO calculation, which is based on historical data gathered by Boehm in 1981. Here's a COCOMO-81 calculator in case you want to play with your own code. Sometimes its estimates are pretty good, but I've sometimes found that applying line counts from my projects in some modern languages (especially functional ones like Scala) throw it off. That could definitely affect the "1,356 developers 30 years" estimate in the article.
Search your favorite job postings website for project manager jobs. Ten out of ten of them will say that a PMP certification is either required or preferred.
A few reasons employers look for a PMP certification: a) several years of professional project management experience are required in order to qualify to take the exam, b) it shows a certain level of commitment to furthering one's career as a project manager, and c) if someone has taken and passed the PMP exam, it means they're at least familiar with standard project management tools, techniques, and practices.
Tom me, those seem like reasonable reasons for adding the PMP certification as a requirement for a project manager job posting. But it definitely means that if you want to move your project management career forward, you should really consider the PMP certification.
Are 'config t' and 'write erase' too difficult to remember? Bothered by all those inconvenient keystrokes? Try the new EasyBoot(TM) from Cisco, the most convenient way to reset your router!
I know a lot of us like to blame people for their own problems, but in this case he knows it's his own fault—which, to me, makes the whole situation even more sad and awful. I feel really bad for him, and I hope he can find a way to come back from this.
From TFA:
“I look around my house and see images of my son and feel such intense shame and crippling sadness,” Pranger wrote on Facebook. “I know that if I can’t find a job at least as good as this one, I won’t be able to provide for my family I’ve lost them their health coverage and their security. I also know that I’ve probably lost a good deal of my friends, just because I know how hard it can be to stay in touch with someone when the convenience of proximity is lost. I’m so sorry to everyone. I’ve failed you. You believed in me and supported me and trusted me and I’ve failed you. I’ve failed me.”
Last time this project was posted here the lead researcher on the project answered questions, including addressing why they developed their own external language rather than using C/C++/Java/Python:
A. Robot swarms are a special kind of system. It's not just a collection of computers (like a network would be), but a collections of autonomous devices that occupy space and form networks with very volatile topology. Sure one could use C/C++/Java/Python to program them, but it gets fast very complex, due to the large number of interactions among robots. We believe that it's much better to have a language that natively provides you with the right kind of abstraction, and hides whatever is not necessary for swarm-level coordination.
You're definitely right about the Wikipedia article glossing over some of the specifics, but I'm not sure I agree that the dichotomy is false. (I'll have to dust off the cobwebs a bit—I first learned this stuff when I was studying CS at Carnegie Mellon way back in the early '90s.:)
My understanding is that one important reason to separate the literal function from the closure (function + scope) has to do with separating syntax from semantics. You the function itself just gives you the symbol manipulation; you can't interpret the meaning of it until you have its context, in the form of a scope (or stack frame, etc.).
Symbolic manipulation versus semantic meaning is really important when you're proving things like computability. I remember back in a graduate mathematical logic course, we used only formal logic to prove some complex fundamental theorem of calculus—but the meaning of that theorem was completely irrelevant, we did the proof entirely through symbol manipulation. So we were able to derive the proof syntactically, without any of the calculus semantics. Not sure if that helps illustrate the difference. Like I said, it's been a while since I studied this stuff.:)
From a more practical perspective, this matters a lot when doing compiler optimization. When you use an anonymous function—where "anonymous" literally just means "doesn't have a name"—a typical compiler will do all sorts of optimizations. I see this a lot when doing.NET programming: if you have an anonymous method that has the same contents as a named method, the C# compiler will just call it, or if the anonymous method is only called once, it may just embed it directly into the calling method, etc. (You can actually see this yourself by writing some code, compiling it, and using ildasm to look at the byte code.) Capture is really important here: this won't work with a closure, because it has the scope. However, a lot of times something that looks like a closure doesn't actually require the scoped variables, or they can be passed in as references, so it can be compiled into an anonymous function.
I've been doing a lot of Scala programming lately, and it's done a lot differently behind the scenes in Scala—and the delineation between anonymous and named is a lot more blurry from a compiler perspective. If you define a Scala function:
this looks a lot like it takes as its f parameter the kind of method that's compiled into a compiler-named anonymous method. But Scala is bytecode-compatible with Java, so this is actually done on the object level—you can pass it an instance of an object (in this case, an instance of scala.runtime.AbstractFunction1):
static Function1 FunctionObj = new AbstractFunction1() {
@Override
public Object apply(Object i) {
return (Integer)i + 6;
} };
and call it like this from Java:
MyScalaObj.runAFunction(FunctionObj);
So when the Scala compiler compiles an anonymous method, it generates an object like FunctionObj. The reason this is relevant is because what looks anonymous to Scala is actually not just a function with a stack context, but in fact an actual object on the heap. This is about as far from a literal function as you can get.
Technically, the anonymous function is just the literal in code, and it's only "anonymous" because the programmer didn't give it a name—the compiler will sometimes assign it a generated name, but it will sometimes do something else (eg. reuse code from elsewhere in the program, roll the function into the caller, etc.). It becomes a closure when that function is combined with a scope.
So higher level function would return a closure value, which would be the function bound to the values in scope. Those aren't the same thing as anonymous functions. For example, they could all be reusing the same anonymous function—that function might be compiled into one location in the assembly or bytecode (if it's.NET bytecode, for example, it might have a generated name like "b__0"), and then called from within scope.
A composed function would generate another literal function valuelike if you have two functions F and G and compose them into lambda(i) => F(i) + G(i), then that lambda would return an anonymous function. But if you assign it to a variable and call it, then it's bound to a scope and becomes a closure.
The term closure is often mistakenly used to mean anonymous function. This is probably because many programmers learn about both concepts at the same time, in the form of small helper functions that are anonymous closures. An anonymous function is a function literal without a name, while a closure is an instance of a function, a value, whose non-local variables have been bound either to values or to storage locations (depending on the language; see the lexical environment section below).
Update, June 21st 9:45AM: Microsoft has updated its blog post today and removed references to "remain activated." The stealthy edit isn't acknowledged, and we've reached out to the company for comment.
Origami is the Japanese art of paper folding created by Akira Yoshizawa, which can be used to create beautiful birds, frogs and other small sculptures.
According to that page, Akira Yoshizawa was born in 1911. Origami dates back to at least 1797, when the first known origami book was published (see the history of Origami).
My dad ran the epidemiology department for the American Cancer Society when I was a pre-teen and teenager in the '80s. I grew up dialing into their VAX 11/780 with a 300 baud acoustic coupler modem. At first I used a DECwriter terminal, which didn't have a screen—all the output was noisily printed to 132-column tractor feed. Eventually my folks brought home a VT180, around the same time that we upgraded to a 1200 baud modem. I'll never forget playing Crystal Caverns, and creating ASCII "animations" as a kid that scrolled up the screen.
Also, it means that as a 9-year-old kid, FORTRAN 77 was my first programming language. I think in some cultures that qualifies as child abuse.
TFA lays out a template for getting press for lousy research: publish a paper (doesn't matter where), create an institute and a website, write press releases that lazy journalists can copy almost verbatim. I don't see why this won't work for legitimate and useful science.
This is great news. For those who haven't been following it, white nose syndrome is an emergent disease affecting bats. It's caused by a fungus that grows on the skin of the animals, and has been killing millions of bats across many parts of the eastern United States (map). A decontamination protocol has been established for researchers and cavers who come into contact with the animals. This is the first really optimistic piece of news about the disease that I've seen.
Plus, public sector workers at least have some job security. I've worked in the private sector for 20+ years, there's a reason it's called "at-will" employment. Sticking your neck out to report a breach won't win you any friends, doesn't gain you anything, and if it get someone who's politically savvy in trouble it could blow back on you. Safer and easier to keep quiet and keep your job.
I wish it weren't like that—and to be fair, the best teams I've worked with weren't (and aren't!) like that. But way too many offices run that way, and politics and sleaziness beats honesty and ethics nine times out of ten.
I'm seeing posts from people saying things like, "Agile isn't working for my team, I just spent my whole daily standup reading this thread" or, "I get a lot of work done during my retrospectives". Of course agile sucks for these people! Agile will get limited—but still useful—results when the team has this attitude.
But if they have a different mindset where they actually try during the daily standup or retrospective, it works so much better.
Look, every really good developer I've worked with has had good opinions and ideas about how the project should be run. When they spend the entire standup or retrospective looking at on their phones, the team doesn't get the benefit of those opinions and ideas. But when they use the meeting to actually share those ideas, and maybe even engage in a good discussion (or even argue for them!) with the rest of the team, the whole project benefits. But that only works if they care about doing a good job with the standup or the retrospective the way they care about doing a good job with their code.
I'm plugging my book, Learning Agile, now. I hope you don't mod me down too much for that. But I think we did a pretty good job arguing this point in the first few pages the first chapter. You can read the first chapter for free [PDF].
A friend of mine was managing a programming team. They interviewed a really good developer in his early 40s, and one of her team members said he was too old. He thought the guy couldn't possibly be up to date on recent technology. She hired him anyway, and he did really good work.
That was well over ten years ago. The guy who raised the objection is now older than the candidate he wanted to reject. I wonder if he's gone on any interviews lately (or found newfangled technology impossible to keep up with).
I know several people who get barometric migraines, or migraine headaches that are triggered when the pressure changes suddenly (usually when it drops). Some of them have told me that migraine medications like rizatriptan and sumatriptan can be effective, but often come with unpleasant side-effects like a racing pulse or grogginess.
This leads to a dilemma: do you take the medication and deal with the side effects, or do you try to ride out the headache? It's especially frustrating for people who get headaches that aren't always migraines, because the migraine medication doesn't necessarily work on a normal, non-migraine headache.
This is where a personal barometric pressure monitor that's been with you for the last few hours can be very helpful. If you are trying to decide whether or not to take migraine medication, you can consult your phone and see if you personally experienced a large pressure drop prior to the onset of the migraine. If so, that helps with the decision of whether or not to take the medicine.
Slashdot Mirror
I've seen occasional questions about IFTTT security issues (link, link, link), but nothing that isn't theoretical or speculative. Seems like there are a lot of avenues for compromising your network security and privacy. I'd love to see some hard facts about IFTTT security.
I bet one of those AIs would pass a Turing test—and not the one that can win at Jeopardy or beat a Go champion.
WARNING: If you're "still" using a computer that's more than 2 years old because its good enough, this post may male you feel like you made the right decision.
Sad? No, this is sad. I would love to buy a new Apple (I need a laptop, and I need to stick with Apple because of various constraints). Unfortunately, they won't sell me a new one that's much better than my "sad" old one.
I started looking for a replacement for my 2012 MacBook Pro a few months ago, fully expecting to buy myself a performance boost. I couldn't believe that Apple simply doesn't make a laptop that's significantly faster than my four year old computer.
Here's the benchmark for my 2012 MacBook Pro: http://browser.primatelabs.com/geekbench3/4933459
Compare that with the results from recent MBPs: http://browser.primatelabs.com/mac-benchmarks
Wow. It's four years later and I still can't buy a significant performance boost from Apple. The best I can do is an almost unnoticeable bump in speed.
Maybe more people would stop using "sad" old computers if Apple gave them a compelling reason to upgrade.
Annoying? Only like someone who never had a boot sector virus wipe out half their files because it detected it was the 26th of the month would dismiss DOS viruses as "anoying". Or, worse, someone who never had to work on a support desk when that happened.
Or someone who's only lived in a time when all computers are networked, so backing up a hard drive doesn't involve swapping 3.5" (or 5.25"!!) floppies in and out of your machine for half an hour, or waiting two hours for your tape backup to finish.
Annoying? Ha.
I think git can meet all of your needs, and personally I love it.
- It's a free, well-established, and well-documented open source project.
- There are plenty of GUIs.
- For inexperienced developers, there are tutorials like this one.
- Here's decent guide to getting password-less authentication via ssh working on Windows to connect to a server running locally on a Windows box (as long as it's running OpenSSH, maybe via cygwin).
- You can use Git hooks to do notifications, run syntax checks, etc.
For those who don't know, COCOMO is an algorithm that was developed in 1981 by Barry Boehm for estimating the cost of building software (typically in person-hours). The numbers in the article were generated by the basic COCOMO calculation in David Wheeler's free SLOCCount toolset.
One drawback is that SLOCCount uses the basic COCOMO calculation, which is based on historical data gathered by Boehm in 1981. Here's a COCOMO-81 calculator in case you want to play with your own code. Sometimes its estimates are pretty good, but I've sometimes found that applying line counts from my projects in some modern languages (especially functional ones like Scala) throw it off. That could definitely affect the "1,356 developers 30 years" estimate in the article.
Wheeler has a good discussion of COCOMO in SLOCCount if you want to learn more about it.
How to fake fingerprints, in case you want to know what to do with them.
Search your favorite job postings website for project manager jobs. Ten out of ten of them will say that a PMP certification is either required or preferred.
A few reasons employers look for a PMP certification: a) several years of professional project management experience are required in order to qualify to take the exam, b) it shows a certain level of commitment to furthering one's career as a project manager, and c) if someone has taken and passed the PMP exam, it means they're at least familiar with standard project management tools, techniques, and practices.
Tom me, those seem like reasonable reasons for adding the PMP certification as a requirement for a project manager job posting. But it definitely means that if you want to move your project management career forward, you should really consider the PMP certification.
Are 'config t' and 'write erase' too difficult to remember? Bothered by all those inconvenient keystrokes? Try the new EasyBoot(TM) from Cisco, the most convenient way to reset your router!
I know a lot of us like to blame people for their own problems, but in this case he knows it's his own fault—which, to me, makes the whole situation even more sad and awful. I feel really bad for him, and I hope he can find a way to come back from this.
From TFA:
Last time this project was posted here the lead researcher on the project answered questions, including addressing why they developed their own external language rather than using C/C++/Java/Python:
And also, another reason:
Most animals don't live in a society, so the concept doesn't apply. Animals that do live in a society do have social justice ("justice in terms of the distribution of wealth, opportunities, and privileges within a society"). Some animal societies (eg. bee colonies) do a lot of resource sharing. It's not hard to see why this would be a useful group behavior to evolve.
You're definitely right about the Wikipedia article glossing over some of the specifics, but I'm not sure I agree that the dichotomy is false. (I'll have to dust off the cobwebs a bit—I first learned this stuff when I was studying CS at Carnegie Mellon way back in the early '90s. :)
My understanding is that one important reason to separate the literal function from the closure (function + scope) has to do with separating syntax from semantics. You the function itself just gives you the symbol manipulation; you can't interpret the meaning of it until you have its context, in the form of a scope (or stack frame, etc.).
Symbolic manipulation versus semantic meaning is really important when you're proving things like computability. I remember back in a graduate mathematical logic course, we used only formal logic to prove some complex fundamental theorem of calculus—but the meaning of that theorem was completely irrelevant, we did the proof entirely through symbol manipulation. So we were able to derive the proof syntactically, without any of the calculus semantics. Not sure if that helps illustrate the difference. Like I said, it's been a while since I studied this stuff. :)
From a more practical perspective, this matters a lot when doing compiler optimization. When you use an anonymous function—where "anonymous" literally just means "doesn't have a name"—a typical compiler will do all sorts of optimizations. I see this a lot when doing .NET programming: if you have an anonymous method that has the same contents as a named method, the C# compiler will just call it, or if the anonymous method is only called once, it may just embed it directly into the calling method, etc. (You can actually see this yourself by writing some code, compiling it, and using ildasm to look at the byte code.) Capture is really important here: this won't work with a closure, because it has the scope. However, a lot of times something that looks like a closure doesn't actually require the scoped variables, or they can be passed in as references, so it can be compiled into an anonymous function.
I've been doing a lot of Scala programming lately, and it's done a lot differently behind the scenes in Scala—and the delineation between anonymous and named is a lot more blurry from a compiler perspective. If you define a Scala function:
object MyScalaObj { runAFunction(f: Int => Int) { println(f(3)) } }
this looks a lot like it takes as its f parameter the kind of method that's compiled into a compiler-named anonymous method. But Scala is bytecode-compatible with Java, so this is actually done on the object level—you can pass it an instance of an object (in this case, an instance of scala.runtime.AbstractFunction1):
static Function1 FunctionObj = new AbstractFunction1() {
@Override
public Object apply(Object i) {
return (Integer)i + 6;
}
};
and call it like this from Java:
MyScalaObj.runAFunction(FunctionObj);
So when the Scala compiler compiles an anonymous method, it generates an object like FunctionObj. The reason this is relevant is because what looks anonymous to Scala is actually not just a function with a stack context, but in fact an actual object on the heap. This is about as far from a literal function as you can get.
And now you know why I thanked Bob Harper in the preface to my most recent book. :)
Technically, the anonymous function is just the literal in code, and it's only "anonymous" because the programmer didn't give it a name—the compiler will sometimes assign it a generated name, but it will sometimes do something else (eg. reuse code from elsewhere in the program, roll the function into the caller, etc.). It becomes a closure when that function is combined with a scope.
So higher level function would return a closure value, which would be the function bound to the values in scope. Those aren't the same thing as anonymous functions. For example, they could all be reusing the same anonymous function—that function might be compiled into one location in the assembly or bytecode (if it's .NET bytecode, for example, it might have a generated name like "b__0"), and then called from within scope.
A composed function would generate another literal function valuelike if you have two functions F and G and compose them into lambda(i) => F(i) + G(i), then that lambda would return an anonymous function. But if you assign it to a variable and call it, then it's bound to a scope and becomes a closure.
Make sense?
Minor apologies for being a bit pedantic, but just in case anyone's confused by the possible misuse of the term "closure" in the summary...
From the Wikipedia entry on closures:
From TFA:
I bet /. comments helped encourage this.
According to that page, Akira Yoshizawa was born in 1911. Origami dates back to at least 1797, when the first known origami book was published (see the history of Origami).
My dad ran the epidemiology department for the American Cancer Society when I was a pre-teen and teenager in the '80s. I grew up dialing into their VAX 11/780 with a 300 baud acoustic coupler modem. At first I used a DECwriter terminal, which didn't have a screen—all the output was noisily printed to 132-column tractor feed. Eventually my folks brought home a VT180, around the same time that we upgraded to a 1200 baud modem. I'll never forget playing Crystal Caverns, and creating ASCII "animations" as a kid that scrolled up the screen.
Also, it means that as a 9-year-old kid, FORTRAN 77 was my first programming language. I think in some cultures that qualifies as child abuse.
TFA lays out a template for getting press for lousy research: publish a paper (doesn't matter where), create an institute and a website, write press releases that lazy journalists can copy almost verbatim. I don't see why this won't work for legitimate and useful science.
This is great news. For those who haven't been following it, white nose syndrome is an emergent disease affecting bats. It's caused by a fungus that grows on the skin of the animals, and has been killing millions of bats across many parts of the eastern United States (map). A decontamination protocol has been established for researchers and cavers who come into contact with the animals. This is the first really optimistic piece of news about the disease that I've seen.
People will trade their passwords for a candy bar.
Plus, public sector workers at least have some job security. I've worked in the private sector for 20+ years, there's a reason it's called "at-will" employment. Sticking your neck out to report a breach won't win you any friends, doesn't gain you anything, and if it get someone who's politically savvy in trouble it could blow back on you. Safer and easier to keep quiet and keep your job.
I wish it weren't like that—and to be fair, the best teams I've worked with weren't (and aren't!) like that. But way too many offices run that way, and politics and sleaziness beats honesty and ethics nine times out of ten.
I'm seeing posts from people saying things like, "Agile isn't working for my team, I just spent my whole daily standup reading this thread" or, "I get a lot of work done during my retrospectives". Of course agile sucks for these people! Agile will get limited—but still useful—results when the team has this attitude.
But if they have a different mindset where they actually try during the daily standup or retrospective, it works so much better.
Look, every really good developer I've worked with has had good opinions and ideas about how the project should be run. When they spend the entire standup or retrospective looking at on their phones, the team doesn't get the benefit of those opinions and ideas. But when they use the meeting to actually share those ideas, and maybe even engage in a good discussion (or even argue for them!) with the rest of the team, the whole project benefits. But that only works if they care about doing a good job with the standup or the retrospective the way they care about doing a good job with their code.
I'm plugging my book, Learning Agile, now. I hope you don't mod me down too much for that. But I think we did a pretty good job arguing this point in the first few pages the first chapter. You can read the first chapter for free [PDF].
A friend of mine was managing a programming team. They interviewed a really good developer in his early 40s, and one of her team members said he was too old. He thought the guy couldn't possibly be up to date on recent technology. She hired him anyway, and he did really good work.
That was well over ten years ago. The guy who raised the objection is now older than the candidate he wanted to reject. I wonder if he's gone on any interviews lately (or found newfangled technology impossible to keep up with).
I know several people who get barometric migraines, or migraine headaches that are triggered when the pressure changes suddenly (usually when it drops). Some of them have told me that migraine medications like rizatriptan and sumatriptan can be effective, but often come with unpleasant side-effects like a racing pulse or grogginess.
This leads to a dilemma: do you take the medication and deal with the side effects, or do you try to ride out the headache? It's especially frustrating for people who get headaches that aren't always migraines, because the migraine medication doesn't necessarily work on a normal, non-migraine headache.
This is where a personal barometric pressure monitor that's been with you for the last few hours can be very helpful. If you are trying to decide whether or not to take migraine medication, you can consult your phone and see if you personally experienced a large pressure drop prior to the onset of the migraine. If so, that helps with the decision of whether or not to take the medicine.
Thanks!! It's super gratifying to hear that! :)