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.
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.
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.
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.
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.
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.
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.
I'd give you mod points if I had some. Tesla has had a nightmare trying to sell direct to their customers because they of the political ramifications. They will need to play by those rules if they truly want to play ball.
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.
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.
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.
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.
One advantage to 3D printing and modelling is that the device can be optimized. They can dynamically change things such as the shape and thickness of materials and inner chamber and then determine whether it made a difference or not. And, they can do it cheaply. I wonder, can they reuse the plastic from earlier models?
More power to them for doing this. As I haven't had time to read the article, are they publishing their design as open source?
This is correct. They also muck with your body's insulin production. This is problematic for someone with Type 2 diabetes who used to drink a lot of diet soda.
It's hard to justify spending $350 or more on a device that is hobbled by poor battery life, needs to tether to an iPhone 5 or later. And to top it off, the heart rate sensor returns false information intentionally and the oxygen sensor is not enabled. I won't delve into it not working with Android devices simply because it is an Apple product.
The device is a 1.0 model. And, like most 1.0 models, it has flaws. The flaws listed above will keep all but the purest Apple devote away. Our household is predominantly Apple. I enjoy developing apps for iOS and Mac. I even have an iPhone 5 (can't justify the 6 due to the effect of the net cost on our mobile plan and wallet). But, I WILL NOT spend $350 on a device that has so many flaws and a fledgling utility market. Drop the prince to $150 and it will move. At $350, it isn't going to happen anytime soon.
C# and.NET were Microsoft's answer to Borland's Delphi (which was their answer to VB) and Java. They poached Anders from Borland after he created Delphi and they didn't want another ass kicking. I have always wondered if he had the idea for.NET before going to the dark side and that Borland, when they went off their their idiotic Java vision quest and became Inprise, blew him off and Microsoft realized the potential of his vision. He has had free reign pretty much ever since.
I don't dislike the.NET platform. Still, I find it ironic that Microsoft Skype is abandoning the Modern interface and rolling back to the older Win32 version (ironically, written in Delphi).
And, I find it interesting that Delphi has been rising on the Triobe index (currently, at #10...just behind JavaScript) after everyone predicted its certain demise. C# is in the 4th place and rising.
RemObjects has developed an implementation of Swift in a product called "Silver" that, per their website, claims:
"With Silver, you can use Swift to write code directly against the.NET, Java, Android and Cocoa APIs. And you can also share a lot of non-UI code between platforms."
Their implementation isn't open source...but, the tool and their implementation are free.
Good info. I don't do active Android dev work right now. I would suspect that (and, your experience demonstrates), Android Studio is the preferred and most up-to-date Android dev tool.
I never ran into an issue with importing Eclipse projects in the past. Maybe a version 14 thing?
Thanks again for sharing your experience with the two products.
Re:Still use the most productive IDE
on
Choosing the Right IDE
·
· Score: 3, Informative
I would agree with you as I prefer Delphi for my personal work or for prototyping a solution. Others here couldn't give a rats ass about a tool they consider obsolete.
As for IDE vs CLI? I prefer IDE. Others a text editor with, maybe, syntax highlighting. More power to them. A good IDE brings everything together, such a code, device views, active debugging, compiler, UML design tools, etc., into a single environment. Managing things such as refactoring, unit testing, code analysis, documentation and other tasks is a big help.
I will not argue with those who prefer CLIs as some people are simply more efficient with the CLI over an IDE. Personally, I would give those in my shop the option to use alternative tools provided the code is properly written, bug free and able to be used, with ease, with the selected IDE.
I do require a lot of screen real estate regardless. One can never have too much screen real estate when debugging when using a text editor or IDE.
My favorite IDEs? Java - IntelliJ (from JetBrains) PHP - PHPStorm (derived from IntelliJ) Android - Android Studio (derived from IntelliJ) iOS/Mac - XCode, RemObject Silver (debate is out) and AppCode (derived from IntelliJ).
For cross platform, prototyping and personal work, I prefer Delphi / RADStudio with VisualParadigm for real UML work.
Stress in the workplace has always existed. Granted, this generation tends to communicate more but using tools such as Instagram and Twitter where the communications are short, don't convey much information and are non-personal. Granted, the older generation used email (after the memo went the way of the dinosaur)- primarily to put the discussion into a more formal written form. The phone or in-person conversation allows one to hear the emotion and concerns of the other party. It's easier to resolve issues when speaking with the other parties than to try to hash it out over email or some chat technology for all but the simplest of issues.
The other night, there was the discussion on why hiring an older person wasn't such a good idea with one person insinuated they (older workers) wouldn't work late nights on a regular basis to get the project done. Someone with experience knows that proper planning and design can alleviate most of those late night coding cycles. As such, they are inclined to find a better balance between home and work and still get their work done without burning the candle at both ends. They also know when late night exercises ARE useful or necessary.
What we old fogies have a hard time dealing with is being treated (along with our coworkers) like a disposable napkin. Workplaces that foster that attitude coupled with limited human interactivity breeds stress. And, that stress doesn't know generational boundaries.
The Live Chat Customer Service opportunity is probably with Comcast in Philadelphia. Initially, I received the request from some recruiters I trusted. Then, a week or two later, it seems like every other opportunity is an exciting op with them. Like the guy who set up the norecruiterspam.com site, I have been working on ways to screen these dups out as well as identify the harvesters as well as deal with UEC and their requirements as well. Yes, I AM on the job market after my position was eliminated last month. It sucks.
Not exactly what I meant. Yes, records need to have an secure audit trail as part of HIPAA. I am talking about watching transactions being made against someone's health/medical record and determining if it is likely fraud. Right now, that doesn't happen due to each institution having their own copy.
For example, if someone enters a hospital claiming to be me (but, in a different state), why can't they request verification (maybe, through a mobile app) that it is me?
If they can't obtain verification from me (such as it is me but I am unable to respond) in a reasonable time period, then there needs to be a fallback procedure such as verifying with a relative that I might be in that particular hospital. And, any transactions against MY health record need to be kept separate until verified. That would keep someone from having surgery, billing it to MY insurance, and having it recorded that I had a kidney removed or hysterectomy (I am a male).
These sort of protections and verifications ARE NOT rocket science.
Slashdot Mirror
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.
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.
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.
However, there is no cost if you don't hit "Send". You have the option to cancel the text just as we have done for years with mailto: links.
Now, if they figure out how to actually send the text without consent, that's another game altogether.
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.
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.
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.
Next, we will hear how he was attacked by an inflatable flying shark.
Seriously, this is a pretty radical advance.
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.
I'd give you mod points if I had some. Tesla has had a nightmare trying to sell direct to their customers because they of the political ramifications. They will need to play by those rules if they truly want to play ball.
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.
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.
http://arstechnica.com/securit...
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.
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.
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.
One advantage to 3D printing and modelling is that the device can be optimized. They can dynamically change things such as the shape and thickness of materials and inner chamber and then determine whether it made a difference or not. And, they can do it cheaply. I wonder, can they reuse the plastic from earlier models?
More power to them for doing this. As I haven't had time to read the article, are they publishing their design as open source?
This is correct. They also muck with your body's insulin production. This is problematic for someone with Type 2 diabetes who used to drink a lot of diet soda.
The idea wasn't that far fetched. It would have been almost impossible to sink and heavily armoured. Picrete is some some cool stuff (pun intended).
It's hard to justify spending $350 or more on a device that is hobbled by poor battery life, needs to tether to an iPhone 5 or later. And to top it off, the heart rate sensor returns false information intentionally and the oxygen sensor is not enabled. I won't delve into it not working with Android devices simply because it is an Apple product.
The device is a 1.0 model. And, like most 1.0 models, it has flaws. The flaws listed above will keep all but the purest Apple devote away. Our household is predominantly Apple. I enjoy developing apps for iOS and Mac. I even have an iPhone 5 (can't justify the 6 due to the effect of the net cost on our mobile plan and wallet). But, I WILL NOT spend $350 on a device that has so many flaws and a fledgling utility market. Drop the prince to $150 and it will move. At $350, it isn't going to happen anytime soon.
C# and .NET were Microsoft's answer to Borland's Delphi (which was their answer to VB) and Java. They poached Anders from Borland after he created Delphi and they didn't want another ass kicking. I have always wondered if he had the idea for .NET before going to the dark side and that Borland, when they went off their their idiotic Java vision quest and became Inprise, blew him off and Microsoft realized the potential of his vision. He has had free reign pretty much ever since.
I don't dislike the .NET platform. Still, I find it ironic that Microsoft Skype is abandoning the Modern interface and rolling back to the older Win32 version (ironically, written in Delphi).
And, I find it interesting that Delphi has been rising on the Triobe index (currently, at #10...just behind JavaScript) after everyone predicted its certain demise. C# is in the 4th place and rising.
http://elementscompiler.com/el...
RemObjects has developed an implementation of Swift in a product called "Silver" that, per their website, claims:
"With Silver, you can use Swift to write code directly against the .NET, Java, Android and Cocoa APIs. And you can also share a lot of non-UI code between platforms."
Their implementation isn't open source...but, the tool and their implementation are free.
Good info. I don't do active Android dev work right now. I would suspect that (and, your experience demonstrates), Android Studio is the preferred and most up-to-date Android dev tool.
I never ran into an issue with importing Eclipse projects in the past. Maybe a version 14 thing?
Thanks again for sharing your experience with the two products.
I would agree with you as I prefer Delphi for my personal work or for prototyping a solution. Others here couldn't give a rats ass about a tool they consider obsolete.
As for IDE vs CLI? I prefer IDE. Others a text editor with, maybe, syntax highlighting. More power to them.
A good IDE brings everything together, such a code, device views, active debugging, compiler, UML design tools, etc., into a single environment. Managing things such as refactoring, unit testing, code analysis, documentation and other tasks is a big help.
I will not argue with those who prefer CLIs as some people are simply more efficient with the CLI over an IDE. Personally, I would give those in my shop the option to use alternative tools provided the code is properly written, bug free and able to be used, with ease, with the selected IDE.
I do require a lot of screen real estate regardless. One can never have too much screen real estate when debugging when using a text editor or IDE.
My favorite IDEs?
Java - IntelliJ (from JetBrains)
PHP - PHPStorm (derived from IntelliJ)
Android - Android Studio (derived from IntelliJ)
iOS/Mac - XCode, RemObject Silver (debate is out) and AppCode (derived from IntelliJ).
For cross platform, prototyping and personal work, I prefer Delphi / RADStudio with VisualParadigm for real UML work.
Stress in the workplace has always existed. Granted, this generation tends to communicate more but using tools such as Instagram and Twitter where the communications are short, don't convey much information and are non-personal. Granted, the older generation used email (after the memo went the way of the dinosaur)- primarily to put the discussion into a more formal written form. The phone or in-person conversation allows one to hear the emotion and concerns of the other party. It's easier to resolve issues when speaking with the other parties than to try to hash it out over email or some chat technology for all but the simplest of issues.
The other night, there was the discussion on why hiring an older person wasn't such a good idea with one person insinuated they (older workers) wouldn't work late nights on a regular basis to get the project done. Someone with experience knows that proper planning and design can alleviate most of those late night coding cycles. As such, they are inclined to find a better balance between home and work and still get their work done without burning the candle at both ends. They also know when late night exercises ARE useful or necessary.
What we old fogies have a hard time dealing with is being treated (along with our coworkers) like a disposable napkin. Workplaces that foster that attitude coupled with limited human interactivity breeds stress. And, that stress doesn't know generational boundaries.
The Live Chat Customer Service opportunity is probably with Comcast in Philadelphia. Initially, I received the request from some recruiters I trusted. Then, a week or two later, it seems like every other opportunity is an exciting op with them. Like the guy who set up the norecruiterspam.com site, I have been working on ways to screen these dups out as well as identify the harvesters as well as deal with UEC and their requirements as well. Yes, I AM on the job market after my position was eliminated last month. It sucks.
Not exactly what I meant. Yes, records need to have an secure audit trail as part of HIPAA. I am talking about watching transactions being made against someone's health/medical record and determining if it is likely fraud. Right now, that doesn't happen due to each institution having their own copy.
For example, if someone enters a hospital claiming to be me (but, in a different state), why can't they request verification (maybe, through a mobile app) that it is me?
If they can't obtain verification from me (such as it is me but I am unable to respond) in a reasonable time period, then there needs to be a fallback procedure such as verifying with a relative that I might be in that particular hospital. And, any transactions against MY health record need to be kept separate until verified. That would keep someone from having surgery, billing it to MY insurance, and having it recorded that I had a kidney removed or hysterectomy (I am a male).
These sort of protections and verifications ARE NOT rocket science.