Youry's Blog

Youry's Blog

Archive for November 2012

“Kill the Password: Why a String of Characters Can’t Protect Us Anymore” By Mat Honan 11.15.12

leave a comment »

Kill the Password: Why a String of Characters Can’t Protect Us Anymore
By Mat Honan 11.15.12 6:30 AM

“It’s not a well-kept secret, either. Just a simple string of characters—maybe six of them if you’re careless, 16 if you’re cautious—that can reveal everything about you. Your email. Your bank account. Your address and credit card number. Photos of your kids or, worse, of yourself, naked. The precise location where you’re sitting right now as you read these words. Since the dawn of the information age, we’ve bought into the idea that a password, so long as it’s elaborate enough, is an adequate means of protecting all this precious data. But in 2012 that’s a fallacy, a fantasy, an outdated sales pitch. And anyone who still mouths it is a sucker—or someone who takes you for one.”  see more here http://www.wired.com/gadgetlab/2012/11/ff-mat-honan-password-hacker/all/

Advertisements

Written by youryblog

November 21, 2012 at 9:15 PM

Posted in Business, SecurityNews

IT Business News (some)

leave a comment »

  1. Windows boss shown the door by Rory Cellan-Jones Technology correspondent 13 November 2012 Last updated at 08:32 ET
    The technology world is abuzz today with news of the abrupt departure of a key executive at Microsoft.  Steve Sinofsky is probably the second most important figure at the company after the chief executive Steve Ballmer. Now he is leaving with immediate effect.
    http://www.bbc.co.uk/news/technology-20295359

Written by youryblog

November 14, 2012 at 2:48 PM

Posted in Business, Interesting, IT

Fedora, wine and Windows applications

leave a comment »

Written by youryblog

November 11, 2012 at 5:46 PM

Salaries for graduates and professionals (news)

leave a comment »

  1. Six surprisingly high paying jobs Peter Harris| Jul 3, 2012 11:37 AM http://www.workopolis.com/content/advice/article/2523-six-surprisingly-high-paying-jobs?CID=721:19L:14946 

    Six jobs in technology and design that can earn you over $100k:1.  Mobile applications developer: The rise in popularity of tablets, smartphones and other mobile devices, means more and more companies are developing apps for multiple mobile operating systems. The average starting salaries for mobile app developers range from $72,500 to $102,750.

    2.  Data security analyst: Companies are more and more concerned with online security threats. This makes the people who can analyse, predict and mitigate those risks in high-demand. They can pull in between $83,250 and $124,500, on average.

    3.  Interactive creative director: These are the people who lead interactive creative teams made-up of designers, writers and art directors, who together are responsible for visual and conceptual creative direction and user experience. Their average base salary is between $95,000 to $140,000.

    4.  Business systems analyst: Companies are trying to improve their strategies by collecting more information about their customers, and they need the people who can analyse complex business problems and evaluate how to solve them. The average starting salaries for these people range from $78,500 to $108,750.

    5.  Information architect: IAs help to define a website’s content strategy and design, as well as evaluate audience needs and behaviour to improve the site’s navigation and layout. People in this position usually earn between $90,000 and $140,000.

    6.  User experience (UX) designer: Because so much business is taking place over the Internet now, companies have a growing need for professionals who can help generate positive online experiences for their customers. The average starting pay range for user experience designers is between $80,000 to $120,000.

  2. 10 degrees that earn high starting salaries (and 10 that won’t get you hired at all  Peter Harris| Aug 24, 2012 10:18 AM  http://www.workopolis.com/content/advice/article/2686-10-degrees-that-earn-high-starting-salaries-and-10-that-won-t-get-you-hired-at-all?CID=721:19L:14946
    So, based on figures from Statistics Canada, Robert Half, industry association websites as well as Workopolis’ own data, here are ten career choices that pay much higher starting salaries than those averages:

    1. Dentist: +- $90,000
    2. Petroleum Engineer: +- $86,220
    3. Data security analyst: +- $83,250
    4. Web site developer and user experience designer: +- $80,000
    5. Mobile applications developers: +- $72,500
    6. Financial Controller: +- $70,000
    7. Lawyer: +- $60,000
    8. Accountant: +- $58,750
    9. Nurse: +- $55,000
    10. Business Administration/Management +- $45,000
  3. Demand for Software Engineers Keeps Climbing and So Do the Salaries

InfoWorld, October 18

From http://www.acm.org/membership/careernews/archives/acm-careernews-for-wednesday-november-7-2012/

“For software engineers, skyrocketing demand across the nation is leading to higher salaries and improved career prospects. The U.S. Bureau of Labor Statistics projects 30% job growth in coming years, while CareerCast recently deemed software engineer the all-around best job for 2012. Software engineers with Java, mobile and .Net developer experience are in particular demand. The national average for a software engineer’s base salary is currently $92,648, according to Glassdoor, marking an increase of 2.5% compared to 2011. However, in some geographic locations, the base salary is higher than $100,000 per year.

According to recent data from Glassdoor, Google currently offers the highest average salary among 15 major tech companies at $128,336 per year. Ranked second is Facebook, which pays its software engineers an average of $123,626 per year. Notably, the salary gap between Facebook and Google is closing. In 2011, Google offered an average salary of $114,595 to its developers, while Facebook offered $107,744. Third on the list is Apple, which offers a base software engineer salary of $114,413. In the fourth spot is eBay with $108,809, followed by Zynga at $105,568. Other companies offering more than $100,000 on average include Microsoft ($104,362), Intuit ($103,284), Amazon ($103,070), Oracle ($102,204), Cisco ($101,909), and Yahoo ($100,122).

Ranked by geographic location, companies in the San Francisco Bay Area continue to offer the highest average base salary for software engineers at $107,798. According to a report from CyberCoders earlier this year, San Jose and San Francisco rank first and second as the cities with the highest-paying IT jobs. Seattle ranks next at $102,006. San Diego follows at $93,529, then Boston ($93,403) and New York ($92,701). Meanwhile, Minneapolis-based companies offer the lowest average base salaries to software engineers at $75,032, considerably less than the national average of $92,648. Clustered in the $80,000 range are Philadelphia ($80,270), Dallas/Ft. Worth ($80,947), Phoenix ($80,975), Denver ($83,164), and Portland ($84,793).”

Written by youryblog

November 8, 2012 at 7:08 PM

Posted in Business, IT, SW Eng./Dev.

In memory of Lary Bernstein. “Retrospective of Lawrence Bernstein”, NJIT Software Engineering

leave a comment »

Larry died peacefully at home on Friday November 2, 2012 according to his wishes.

I knew him for several months only (maybe a half of year), last his months, but I was so glad to discuss with him about SW Engineering problems and about SW Engineering teaching at post secondary institutions.

Before his death he sent email to about 70 people with his MyRetro on 20 October 2012. He had cancer. I think I can publish his message on my blog, especially because in the past I already asked his permission to publish our discussions on my blog for my and only for my students and SW Engineers. I think he would be happy to see, that his ideas and his thoughts can be used by other SW Engineers and Computer Scientist even after his death.

May he rest in peace!
++++++++++++++++++++++++++++

Retrospective
Lawrence Bernstein
NJIT Software Engineering adjunct Professor
20 October 2012

I retired after 35 years at Bell Laboratories. I had great jobs there. Where else could a kid come out of Rensselaer Polytechnic Institute with an E.E. degree at the very beginning of the computer revolution and have the opportunity to shape that development?
The summer before my senior year at RPI, I wrote my first program. I had a summer job testing circuit boards for sonar systems. I found a computer closeted away and used it to write a program to compute settings for active sonar systems. I was so proud! It reduced two weeks of design work to 15 minutes. My colleagues were less than thrilled. They tsked over my foolishness in trusting such an unproven thing and went back to their manual design methods. Early Lesson #1: Follow your bliss.
Undeterred by the discouraging words, the following June found me graduated and working at Bell Labs, writing software for an antimissile system. My job was to understand the system design and translate it into a set of specifications for programming warhead detection software. This accidentally provided an early lesson in configuration management.
Sequentially numbered punched cards were used to create test data and, though we passed a software incentive fee test for the project, we did not get consistent results. The culprit was human error. What I thought were 40 cards cycled 1,000 times were actually only 39 cards. The computer center clerk had dropped the deck and never checked that the card order–and number of cards!–was correct before creating the driver magnetic tape. Early Lesson #2: People can confound the best laid plans.
NASA recognized the need for formal configuration management as part of the Apollo program. Their approach of manual punched card manipulation became the foundation for the development of the Source Card Control automated system that was the grandfather of today’s configuration control software tool industry.
The army customer next decided that a system to intercept many warheads in one engagement was critical. Redesign work had to include parallel processing with shared memory and up to ten processors. The National Academy of Sciences opined that such a system could never work. Early Lesson #3: Don’t be discouraged by anything you hear, but listen carefully. You might get a pearl.
My job was to design a task assignment system that spread the work load, honored precedence relations, and met the tight response time requirements of this real-time system. Our design worked, but my colleagues and I considered all suggestions and made special provision to dedicate several processors to battle planning software.
About this time, I realized the wisdom of the magic words, “What changed?” The response is usually “NOTHING,” delivered defensively. Calm insistence on reviewing the configuration often reveals a change deemed harmless to be the culprit. One time we wrote and debugged software to transmit 24 reels of tape containing radar data from a Pacific Ocean island to the east coast of the United States in 36 hours so that Lincoln Labs could determine if solar panels for the Sky Lab had properly deployed. They hadn’t. Early Lesson #4: Check and verify, again and again.
After a series of mostly successful tests on the Pacific Missile Range and the signing of the SALT II anti-missile treaty, I turned my attention to the Bell Telephone companies in the United States. Software was still the poor cousin of the industry. There was little respect for this mysterious stuff that seemed so irritable, so unknowable and yet so critical to the business. This lack of management vision caused a great many young people to be trained in software design and then let go, often to make brilliant careers elsewhere.
I became a software project manager in 1975 for a project called BISCOM that was in a shambles. When the car service drivers for the customers’ executives knew the daily status of BISCOM, things were really bad.
I had many problems to confront. I could not estimate how many people would be needed to create a given set of features or just how long it would take to produce a fully tested release. Too often I found myself explaining what went wrong rather than fixing problems. Fairly soon, though, some solid ground developed.
The relationship between developer and customer is fundamental to success, and prototyping is an excellent method for establishing mutual understanding. I found that teamwork would actually double productivity. It is difficult in the present day to remember just how difficult it was to explain and imagine methods that were essentially invisible to users who had always before had tangible “stuff” to handle.
One executive asked several accomplished software engineers to examine the project and its people. They reported, “Most of the developers have mathematics/computer science backgrounds. Although it is important to have developers with a good understanding of current software tools, it is at least equally as important to have people with sound engineering backgrounds. The mathematician and the engineer each bring to a task different and complementary viewpoints and one rarely finds individuals who can successfully represent both. Future hiring should be of candidates with engineering backgrounds until a better computer science/engineer balance is achieved.”
Was this carefully and dispassionately received by the 1975 BISCOM project management in the spirit in which it was offered? Hardly! “This recommendation is only partially accepted. Although we agree that people must grow to do software engineering and sophisticated design jobs, we do not accept the notion that an engineering background is necessary to achieve these goals.” The engineer vs. computer scientist issue caused the organization to discount the entire audit report but the notion of prototyping was quickly accepted. Early Lesson # 5: Prototype to understand the requirements.
It was the first time I encountered the Computer Science vs. Software Engineering turf battle. Unfortunately, it continues to this day with computer scientists arbitrarily calling themselves engineers, though without the necessary study for the degree.
The computer scientist is needed to produce the working software so that it performs needed features in a trustworthy manner. The software engineer packages the software into a system, solves problems, simplifies high level algorithms, estimates costs and schedules, models system reliability, models the economic value of the projected system and creates architecture and high level interface designs.
This conflict will remain unresolved until liability for failure is assigned to individuals as well as corporations.

WHAT WORKS

1. Start small, 10 to 20% of the ultimate staff, to understand the customer requirements, build a prototype and create a first order architecture. When there are more people available, assign them to learning new technology or the application domain while the high level architecture team performs exploratory development tasks.

2. Cultivate a friendly user site so that the customer’s people feel ownership in the project and help the developers understand what is really needed and meant by the abstract requirements.

3. Hire the best people you can afford, and steer the best of the best to the application. Simplify the product design and algorithms. Design simplification through reuse and redesign works well. Schedule and hold periodic project meetings with a fixed agenda.

4. Invite the customer’s people to offer solutions, but ask your own software engineers to develop THE solution.

5. Create a configuration management organization to maintain the official project libraries, do builds and track changes. This activity is variously called “software manufacturing” or “software administration.”

WHAT DOESN’T WORK
1. Metrics based on lines of code are useless and misleading. Tracking metrics for the sake of having metrics leads to a false sense of management control. For example, I found that the reported number of customer high severity problems, even when the same problem was counted multiple times because it was reported from different installations, was a far better measure than correction reports per thousand lines of source code to measure software product quality and to direct bug fixing efforts.
2. Separating responsibility, accountability, authority and control often leads to chaos and interminable committee work.
3. Taking a one-size fits all approach and expecting the same processes to fit projects of all sizes is a mistake.
4. Insisting on specific software development processes before the project is defined, staffed or organized. The process must fit the problem.
5. Not having assigned people to tool development as the best programmers will migrate from the application to making tools.

After retiring from Bell Labs, I went on to teach at Stevens Institute of Technology and created their Software Engineering Master’s Program. Then I had the opportunity to teach software engineering topics for three years at New Jersey Institute of Technology.
I had a very exciting fifty years helping the software industry grow. It is a shame that we still can not agree that there is a serious and important difference between the computer scientist and the software engineer. Both are needed and both bring special skills and knowledge to building software systems.
Too many in our profession do not read our rich literature. I expected professionals who want me to respect them as software engineers to have studied or at least be familiar with these ten publications:
1. Fred Brooks, The Mythical Man-Month, Anniversary Edition, Fred P. Brooks, Addison-Wesley, 1995, ISBN-10 0-20183595-9
2. D.L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM, Vol. 15, No. 12, Dec. 1972, pp. 1053-1058.
3. B.W. Boehm, “Software Engineering,” IEEE Transactions on Computers, Vol. C-25, No. 12 Dec 1976, pp. 1226-1241 and Software Engineering Economics, Prentice-Hall, 1981, ISBN 0-13-822122-7
5. Albert Endres and Dieter Rombach, A Handbook of Software and Systems Engineering, Pearson Addison-Wesley, 2003, ISBN 0-321-15420-7.
6. Peter G. Neumann, Computer Related Risks, Addison-Wesley, 1995, ISBN 0-201-55805-X.
7. Tom DeMarco & Timothy Lister, Peopleware 2nd ed., Dorset House, 1999, ISBN 0-932633-43-9
8. Martin Fowler, Refactoring Improving the Design of Existing Code, Addison-Wesley, 1999, ISBN 0=2201-4567-2.
9. Hans Van Vliet, Software Engineering Principles and Practice 2nd edition, Wiley, 2000, ISBN 0-471-97508-7.
10. Lawrence Bernstein and C.M. Yuhas, Trustworthy Systems through Quantitative Software Engineering, Wiley, 2005, ISBN 0-471-69691-9

Written by youryblog

November 6, 2012 at 11:04 PM

Oracle Scripts

leave a comment »

  • Cold Backup

I’ve use scripts from internet with my modifications for our local servers. It’s for myself and my colleagues only to help with day-to-day activity.

at the first I prefer to use a short path to the local folder which keeps necessary scripts. I use c:\scripts

good link is here: http://toolkit.rdbms-insight.com/cold_backup_scr.php

She has a copyright, but because she wrote:

“You will have to create two additional files, shutdown.sql and startup.sql — see comments in the second scipt. You will also need to precreate the backup log and, of course, customize the directories and SID for your system.”  “Note: Proofread any scripts before using. Always try scripts on a test instance first. I’m not responsible for any damage, even if you somehow manage to make my scripts corrupt every last byte of your data, set your server on fire and serve you personally with an eviction notice from your landlord!

I assume I have a right to correct her script for my configuration with appropriate credits for her work. If anybody has any problem with the updated script, please let me know. I’ll be happy to remove the updated script from this blog and to write my own. This is only to save my time, because I already wrote a lot of other scripts in the past, but I’ve lost many of them as well.

--------CUT-----------Updated by YK ------------------CUT---------------------

REM make_cold_backup.sql
REM copyright 2001-2004 N Roshak, updated by YK on Sun Vov 4, 2012
REM this is a sql script to generate a DOS backup script

rem YK's correction
connect / as sysdba
set heading off
set pagesize 0
set echo off
set feedback off
set verify off
set linesize 500
col mything for a500
spool C:\scripts\cold_backup.bat
prompt REM Script to take full cold database backup
prompt REM generated by make_cold_backup_scr.sql
prompt REM does not back up tempfiles
prompt REM
REM updated by YK
prompt set oracle_home=C:\ORACLE\PRODUCT\10.2.0
prompt set backup_dir=Y:\klo-sciora-1_backup\coldSCI254Backup
REM corrected by YK on Nov. 4th, 2012
select distinct 'copy ' || leaf
|| ' %backup_dir%' || substr(leaf,instr(leaf,'\',-1,1), length(leaf))
as  cmdstr
from
(select name as LEAF from v$datafile
union
select name from v$controlfile
union
select member from v$logfile)
/
prompt REM Copy init.ora and pwd files
prompt copy %oracle_home%\db_1\database\SPFILESCI254.ORA %backup_dir%\SPFILESCI254.ORA
prompt copy %oracle_home%\db_1\database\PWDsci254.ora %backup_dir%\PWDsci254.ora
spool off
exit

--------CUT-----------------------------CUT---------------------

REM backup.bat
REM this is a DOS batch script
REM to take a full cold backup
REM copyright 2002-2004 N Roshak, updated by YK on Nov 4th, 2012

REM requires two sql scripts in addition to the above sql script:
REM shutdown.sql (connect / as sysdba, shutdown immediate, exit)
REM startup.sql (connect / as sysdba, startup open, exit)

set oracle_home=C:\ORACLE\PRODUCT\10.2.0\db_1
set script_dir=c:\scripts
set shutdown=%script_dir%\shutdown.sql
set startup=%script_dir%\startup.sql
set scriptgen=%script_dir%\sci254ColdBackup.sql
set log=%script_dir%\backup.log

echo >> %log%
echo ----------BEGIN FULL COLD BACKUP OF DB---------- >> %log%
date /T >> %log%
time /T >> %log%
echo Generating cold backup script... >> %log%
%oracle_home%\bin\sqlplus /nolog @%scriptgen%

date /T >> %log%
time /T >> %log%
echo Shutting down... >> %log%

%oracle_home%\bin\sqlplus /nolog @%shutdown%

echo Backing up... >> %log%
call %SCRIPT_DIR%\cold_Backup.bat >> %log% 2>&1

echo Starting up... >> %log%
%oracle_home%\bin\sqlplus /nolog @%startup%

date /T >> %log%
time /T >> %log%
echo Succesfully completed. >> %log%
echo -----------END FULL COLD BACKUP OF DB----------- >> %log%

--------CUT-----------------------------CUT---------------------

Written by youryblog

November 4, 2012 at 5:49 PM

Horror Stories

leave a comment »

I’m starting new blog about “horror stories” in SW Engineering and industry. I think it’s good to know what we could have from some “businessman”.

  1. This box cost Enumclaw fire district $309,794 http://www.pressdisplay.com/pressdisplay/viewer.aspx?newspaper=the+seattle+times+sunday&issue=10632012102800000000001001
    It’s a very good story, when somebody plans to do something fast and cheap, as in this story to get a cheap and old movable home for $85,000 and move it to a very close location, but real price for the relocation can be in two times more expensive than the home. But they did mistake – they bought the home from the wife of an elected official who oversees the district …  The new one would cost $225,000.
  2. I like this paper: Why Projects Fail (Facts and Figures): http://calleam.com/WTPF/?page_id=1445
    Source : IBM
    Type of survey : Survey of 1,500 change management executives
    Date : Oct 2008

    IBM survey in the success / failure rates of “change” projects finds;

    Only 40% of projects met schedule, budget and quality goals
    Best organizations are 10 times more successful than worst organizations
    Biggest barriers to success listed as people factors: Changing mindsets and attitudes – 58%. Corporate culture – 49%.  Lack of senior management support – 32%.
    Underestimation of complexity listed as a factor in 35% of projects

Written by youryblog

November 3, 2012 at 2:37 PM

Posted in Business, Most