Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Slashdot Deals: Deal of the Day - 6 month subscription of Pandora One at 46% off. ×

Comment As a former naval officer... (Score 3, Interesting) 350

Celestial navigation was taught in our Naval Science Navigation course. As naval bridge officers, we were required to learn celestial navigation primarily as tradition and to have a working understanding of the mechanics of the process. That being said, one must know where the ship is at all times. Today, we rely on GPS, inertial navigation systems and the gyroscopic compass (as opposed to a magnetic compass). There have been times when we lost GPS or LORAN C while at sea. We did experience loss of the gyroscopic compass in the middle of ocean and our ship didn't have INS. You have a mission to carry out and that entails safely navigating your vessel.

Basic skills such as dead reckoning and visual position fixes are used when near land. At sea, with no landmarks, knowing where you is just as important. Case in point is that there is an underwater mountain in the Pacific that ships still manage to hit. Avoiding those things is pretty important. Murphy's law will ensure that your ship fill find the underwater mountain or shoal waters if you aren't prepared.

Do navigators take celestial fixes every night the skies are clear? No. They do it from time to time to keep the traditions alive. And, should the skills ever be needed, they will have them. The calculations are tedius and no where as accurate as GPS fix. But, it's an interesting exercise and a time honored tradition.

Comment It wasn't working (Score 2) 78

I use Yahoo! as a throw-away, personal email. Went to use their new notification basis. I never received the token as they claimed I would. Did switch to their SMS version for on-demand passwords. That, actually, did work. Perhaps, the other system is working now and was just experiencing high demand/load issues due to all their users giving it a shot. But, after getting locked out three times trying to use this "feature", I don't think I will try it again anytime soon.

Comment Re:Price curve!! (Score 1) 117

I alluded to this in my last statement. Determining the proper selling price for a market is very much a science as well as trial and error. Sales teams go to great lengths to determine the proper selling prices.

The bottom line is that at the current exchange rates, a developer selling in the lesser performing markets is taking the equivalent of twice the Apple Tax. As I noted, the developer sells their ware at $0.99 in the US. They see only 70% of that income. Given that the AUD's exchange rate is .7, the developer's going to see only $0.49 vs $0.70 per the US market.

The math is pretty straight forward as to what the break even points would need to be at a given effective selling price and number of units sold.

0.49 N1 >= 0.70 N2

You have to sell 1.42 times as many units at the lower price point as the higher price point to break even. When that ratio is exceeded, the lower price point makes sense.

Now, one can argue that the product is being sold in multiple markets and the developer can afford to take less profit since they are still taking a profit. We are only assuming they are turning a profit given the cost to build and market their ware. Who are we to decide what is a fair profit for the seller to take? The decision to sell at the lower effective sales price is the seller's decision to make. And, they will make that decision after analyzing their markets and what the markets determine is a fair price for their product and maximize their profits in a capitalistic fashion (assuming they are capitalists). Or, they can be altruistic, sell at a lower price point, and whatever profit they earn is sufficient.

Comment Core Math at it again... (Score 5, Informative) 117

The title of the parent post is totally misleading and shows a clear sign of not having passed basic algebra. Australians are going to pay 15% more for their apps and not 50%.

First $1 AU = 0.70 US. Taking currency conversion into consideration, this means that a 0.99 App in the US store would cost $1.29 AU.
Next, we see that that $1.29 apps are being raised to $1.49. That's a $0.20 AU or a 15% price hike.

Converting that back to US, we see that the equivalent cost is $1.09 US vs the original $0.99 US. This $0.10 US difference equates to an actual 10% markup between the AU and the US markets.

I would have to assume that Apple is passing on their operational overhead costs in the pricing of apps.

Something to think about - developers are permitted to set the price of their apps. In the US, other than free, the minimum cost is $0.99 as that is the lowest tier that Apple permits. Should developers be forced to take a pay cut because they are selling in a market with a poor currency exchange rate or should they be permitted to sell their wares at a specific price they deem appropriate?

Given that Apple is going to reintroduce a $0.99 tier in those markets, should developers be expected to sell their apps at a 30% discount in the US as well? After the Apple tax of 30% on goods sold in the store, the developer makes a $0.50 on an item they originally sold for $0.99. Is that fair?

If developers are willing to take such a hit on their profits at the benefit of maybe selling more at the lower price and gaining a PR boost, then we will see them moving to the $0.99 plan in those poorer performing markets.

Comment Re:Evolution is key (Score 1) 131

Yes, readability is very important. Sadly, the trend I now see is that those migrating towards a senior role (or, what they believe an EA is) are unable to progress past the first couple of chapters. Had they, actually, had the proper training and mindset, they would be able to understand what the true value an EA brings to a business by having designed a system that is flexible and won't break as the business grows. Instead, we see senior individuals relegated to pasture and younger, less mature and experienced developers calling for a complete redesign (at significant cost) because they simply don't know what they don't know. It's the role of the EA to make sure the purpose and vision of the architecture and product roadmaps are understood by the team. And, they should help identify the weaknesses of their team and get them the training they need (training? Who pays for training???).

On the flip side, I have seen EAs who sit in their office and abstract away and never interact. Keeping your wonderful ideas and visions bottled up simply doesn't cut it. The less senior folks are put off by what they see and, frankly, rightfully so.

I am one of the EAs who has recently been put to pasture. Our organization decided to restructure and move away from developing products and services. Instead, they have decided to concentrate on just one small aspect of the business - the one that corporate felt makes them the most money prior to going public. Developers are left doing the same thing over and over again with no opportunity to step outside the box and expand their knowledge. There is no mentoring. I found myself hindered in my role in how I could interact with and mentor the developers - it was all about billable time vs growth. Now, I am gone - laid off - six months now. The developers have, thankfully, recognized boredom and all except the H1.B's and greencards have left. It's a very shortsighted and, I suspect, they will feel the ramifications in the future. Nah..they won't...they will just hire more H1.B's and greencards to fill the void because they won't rehire those now unemployed because of their shortsighted vision...we're damaged goods.

But, I can't find a job. I am finding that I am either overqualified or not specialized enough in the language/framework of the week or the role of architect is now being filled by organizations paying $80K instead of the $120K+ we used to command for the same "title". Like everyone else, I've got bills to pay. Yet, many hiring managers seem hard pressed to understand that I am comfortable going backwards and doing more coding for less pay. You might say you will never get in this position - I know that's what I did. Surprise.

Comment DICE DISCUS (Score 2) 348

Great....Now, I can get partisan rhetoric and little interesting facts from a bunch of self-proclaimed nerds and blow hards.

Discuss laws and politics that affect us in a real manner such as regulating how we do business. But, attacking for political (and, far too often, inaccurate or debunked) reasons should be limited to DISCUS of FOX News and not here.

Let's not turn /. into DICE DISCUS debacle and reverse course.

Comment Re:Read the comments from the source (Score 5, Informative) 35

Did you actually read the article? They were able to stimulate the nerves in the legs by interpreting the brain waves detected by an electroencephalograph. They acknowledged that there is no feedback to the brain (as of yet) to restore feeling. This has nothing to do with nerve regeneration.

Diabetic neuropathy is the result of damaged nerves from too much glucose. I, like many other diabetics, face it as a real possibility. I also acknowledge that the cause for DN is from the high glucose levels damaging the nerves. Regeneration will only delay the inevitable. Instead, they need to find ways to restore proper insulin production and to reverse insulin resistance.

The technique in the article is a first bridge and a monumental step forward to restoring mobility at a time when nerve regeneration isn't yet possible.

Comment In the #ESTIMATES Camp (Score 4, Interesting) 299

I have worked in the industry for 20+ years and here are my observations - granted, I have worked in smaller companies (i.e 25-4000) and startups.

Estimates work as a means to determine the work effort for a given set of features. They are not to be used for setting schedules and deadlines by themselves. They are to be used for budgeting and cost planning. And, they are not to be done without a detailed design meeting the agreed upon requirements.

Unless your client is very rich and/or stupid or you have a large surplus of venture capital in your startup, you better be concerned with the work effort and time to have your product in a usable state. When you can tell a client that a project is going to take time X and cost Y and meet those values, you gain credibility and trust. In the digital advertising world, those with credibility and trust become the agency of record (AOR). And, the client will stick with you as their AOR until you royally screw up and fail to deliver what was promised, when promised and for the agreed upon price.

You DON'T ask a developer how long something will take - they invariably will underestimate the work effort. Instead, at least until you have measured delivery rates for your team members, you use industry standards. You can ask the developer and then compare their estimates with the actual time and effort. When their estimates start matching up, you can ask them estimate their own assigned work. It can be a good learning experience for them.

Some projects don't require estimates. We had projects that fit a template model based earlier work. We knew how long it took, on average, to fill the various fields of the template. Throw in the project management, QA and deployment components and its pretty easy to do.

When people claim Agile isn't compatible with estimates, it's probably because the team isn't concerned about documentation or planning. They tell you that the system has too many variables and they don't have time or resources to keep the design up to date. I call BS. If you can't do it, then add someone to the team who can. There are great tools for doing design work and capturing requirements at all phases of a project - use them.

Even with Agile, you should layout out a basic design or framework in the early stages of the project. Then, you can determine how long other features will take and what their dependencies are before you attempt to implement them and emptying the client's wallet. Then, you base the number of sprints based on that information. Since you are supposed to have a working product at the end of each sprint, you should be able to tell the client what features will be in each deliverable and cost. If they want to change the requirements or add new features or change functionality, you still have to plan how long those features will take and in which sprint you will deliver a product that meets those changes.

Comment Re: leveraging existing state of the tech (Score 1) 535

Why buy? They just need to partner with a company like Tesla or bail out an existing manufacturer like VW. There is no need to build the infrastructure necessary to build cars when they use another's facilities while adding to the electronic and electrical systems.

Comment Re:Never reuse passwords (Score 1) 146

All it takes is a keylogger to get the master password. There was a recent malware attack (2014) that did this against some of the more popular password managers such as 1Password and...uh...KeePass...on Windows.

Perhaps, using Time-based Two-Factor authentication such as Google's implementation is a safer bet as a keylogger wouldn't capture the tokens on the device running the authenticator code. Alternatively, use an Out of Bounds message, such as an SMS to convey the code to a mobile device which is read and then entered into the system you are trying to access via another device.

Even if they do should obtain your AM userid and password, the odds of them being able to use it against an individual with an account on a TFA protected system is pretty remote. Sadly, TFA is just coming of age and their marriages (and bank accounts) are already coming to end.

Comment Re:Definitely ASN1 (Score 1) 429

I don't recall ASN.1 (or, DER) being a programming language. I recall it being a data description/notation language describing a set of encoding rules that compiled down into a compact binary format. It is the notation (well, the more simplified Distinguished Encoding Rules (DER)) used to describe X.509 certificates and is still in use today but hidden through high level APIs.

Writing encoder and decoders for it was something I had to do when implementing a secure communications program in the early/mid-1990's.

Comment Re: buh, bye (Score 4, Informative) 495

Actually, they weren't trying to eliminate encryption - just limit its strength. Yes, they were trying to implement restrictions as per the ITAR on strong encryption. They were up in arms over PGP being outside of their control. They were trying to force the Clipper encryption chip and Skipjack down our throats. And, Gore was the guy who was pushing these things for the administration with the urging of the 3 letter acronym organization.

Encryption, in the US, would have remained. Clipper, embedded into everything would have allowed law enforcement to decrypt communications using, supposedly, a warrant to obtain the "Law Enforcement Access Field (LEAF)" that would then have allowed the recovery of the encryption key. It probably should have been called the "Law Enforcement Access Key" (wait..that spells LEAK...can't have that). A vulnerability was discovered that enabled a hacker to encrypt communications while bypassing the generation of the LEAF key. That derailed the entire project and Clipper died in 1996.

Yes, I still have my "Sink Clipper" tee shirt from the RSA Data Security conference from back when they were actually trusted.

2 pints = 1 Cavort