새롭고 미성숙 한 기술로 손을 태운 적이 있습니까?
나는 종종 사람들이 새로운 기술이 안정되고 시험되고 테스트 될 때까지 서두르지 말아야한다고 말하는 것을 듣습니다. 3 가지 버전이 필요하다는 농담도 있습니다. 이것은 실제 경험의 목소리 일 수 있지만, 적어도 때때로 그러한 자세는 안일함, 변화에 대한 저항 및 새로운 기술을 배우기 위해 필요한 노력의 결과입니다.
그러나 제 생각에는 소프트웨어 산업의 성공을 위해 혁신 속도를 유지하는 것이 중요합니다. 대기업에는 R & D 전담 부서가 있지만 소규모 기업에서는 개발 팀이 따라 잡아야합니다. 새로운 기술이 공식적으로 출시되기 전에 시작하십시오. 이렇게하면 약간의 유리한 출발을 할 수 있고 나머지를 따라 잡는 데 도움이 될 것입니다.
가능할 때마다 내가 따르려고하는 전략은 다음과 같습니다.
- 새로운 기술 채택에 적극적
- 실험 및 프로토 타입에 초기 베타를 사용하고 개발을 위해 RC를 사용합니다.
- 초기에 채택한 기술의 공식 릴리스가 나올 때 제품의 마지막 순간 변경 사항을 해결합니다.
- 활동이없는 일부 모호한 오픈 소스 프로젝트에 의존하지 마십시오.
- 반드시 연구하되 공식 제품 로드맵을 참고하십시오.
지금까지 저는 새로운 기술 열차에 뛰어 들기에 너무 열심이라는 대가를 지불 한 적이 없었지만 여전히 혜택을 받았습니다. 우연의 일치인지 아니면 얼리 어답터가되는 것이 결국 그렇게 위험하지 않은지 궁금합니다.
조기 채택이라는 주제에 대한 논의에 초대하는 것 이상으로, 그러한 문제는 분명히 논쟁의 여지가 있고 주관적이므로 초기 신기술 채택이 심각한 실수로 판명되고 엄청난 대가를 치러야하는 실제 경험을 듣고 싶습니다. 지불.
저는 현재 Microsoft Office Word 2007의 CustomXML 지원에 의해 구워지는 과정에 있습니다.
CustomXML을 사용하면 문서가 비즈니스 데이터 등을 모델링 할 수있는 사용자 정의 요소를 가질 수 있습니다. 예를 들어 사용자 정의 요소와 XSD를 정의하고 docx 파일과 연결 한 다음 자리 표시자를 CustomXML 태그로 생성하고 다음을 사용하여 문서를 탐색 / 수정할 수 있습니다. C # (또는 기타 .NET 언어) 및 OpenXML SDK . OpenXML의 장점은 자동화를 위해 서버 컴퓨터에 Office를 설치할 필요가 없으며 타사 라이브러리를 구매하는 대신 사용할 수 있다는 것입니다.
간단히 말해 사용자 정의 XML로 문서를 여는 Word 2007의 기능에 대한 소송이있었습니다. 에서 이 문서 :
8 월 11 일 회사는 Office Word 판매 금지 명령을 받았습니다.
"이 금지 명령은 2010 년 1 월 11 일 금지 명령 날짜 이후에 미국에서 판매 된 Microsoft Word 2007 및 Microsoft Office 2007 사본에만 적용됩니다.이 날짜 이전에 판매 된 이러한 제품의 사본은 영향을받지 않습니다."
Microsoft의 대응은 향후 버전의 Word에서 CustomXML에 대한 지원을 제거하고이 기능을 완전히 제거하는 패치를 출시하는 것입니다. 다음은 공식 업데이트에 대한 링크 입니다. 이 Microsoft OEM 파트너 센터 사이트 에 따르면 :
미국에는 다음 패치가 필요합니다. 패치는 모든 Office 2007 언어에서 작동합니다.
이 패치가 설치되면 Word는 더 이상 DOCX, DOCM 또는 XML 파일에 포함 된 사용자 지정 XML 요소를 읽지 않습니다. 이러한 파일은 계속 열리지 만 사용자 지정 XML 요소는 제거됩니다. 사용자 지정 XML 마크 업을 처리하는 기능은 일반적으로 Word 문서의 자동화 된 서버 기반 처리와 관련하여 사용됩니다. 사용자 지정 XML은 일반적으로 대부분의 Word 최종 사용자가 사용하지 않습니다.
최종 사용자와 개발자 중 극히 일부가이를 사용한다고 생각하므로 마지막 문장이 정확하다고 생각합니다. 문제는 현재이 기술을 활용 한 프로젝트를 진행하는 방법에 대한 단어 (말장난 의도 없음)가 없다는 것입니다. CustomXML은 현재 작업중인 대규모 프로젝트의 초석입니다. 이 결정의 영향은 긍정적이지 않으며 CustomXML이 제공 한 구조를 유지하는 동등한 대체 접근 방식이 없기 때문에 향후 호환성을 효과적으로 방지합니다.
제 동료 중 일부와 저는 주제에 대한 풍부한 지식을 가지고 있습니다. 계획 한대로 블로그 게시물을 작성하지 않은 것이 좋았습니다. :) 우리는 이것으로 꽤 인상적인 업적을 달성했습니다. 하지만이 소식은 실망 스럽습니다.
이 주제에 관심이있는 사람은 다음 기사를 참조하십시오.
ZDNet 기사 :
BNet 기사 :
- Microsoft는 빠르게 움직이며 Word 용 사용자 지정 XML 패치를 이미 보유하고 있습니다.
- Microsoft는 Word를 판매하지 않기 위해 주문에서 이점 또는 고통을 얻을 수 있습니다.
Softpedia 기사 :
- Microsoft는 더 이상 Office Word 2010, 2007 또는 2003을 판매 할 수 없습니다.
- Microsoft Dodges Office Word 판매 금지-적어도 일시적
- 사용자 지정 XML 항소가 Microsoft에 거부 된 후 제공되는 새로운 Office 2007 복사본-2010 년부터
편집 : 공식 업데이트에 대한 링크를 추가했습니다.
꽤 좋은 자바 애플릿을 작성할 수 있습니다. 모든 기술은 결국 무너질 것이지만이 기술은 매우 급격히 상승 및 하락했습니다.
몇 년 전에 우리는 Notification Services라는 새로운 SQL Server 2005 기능을 많이 사용했습니다. 실망스럽게도 SQL Server 2008에서는 중단되었습니다. 이것은 심각한 문제 였기 때문에 소프트웨어 설계자는 모든 새로운 Microsoft 기술에 의문을 제기했습니다.
여기에 몇 가지 세부 사항 과 더 많은 것들이 있습니다.
Microsoft의 Entity Framework 에도 문제가 있습니다 .
모든 새로운 Mac 응용 프로그램이 작성되는 방법에 대한 Apple의 아이디어 인 OpenDoc을 기억하는 사람이 있습니까? 그렇게 생각하지 않았습니다.
스칼라.
문서 상으로는 멋져 보이기 때문에 Scala 버전을 최신 상태로 유지하면서 프로젝트를 작성했습니다. 버전 번호 (2.7.x)와 개발 기간은 비교적 안전하다고 느꼈습니다.
글쎄, 내가 실수를 했어. 문제? 문서 및 코드 샘플의 심각한 부족, 끊임없이 변화하는 클래스 라이브러리 (내 작업 중 두 번, 이전에 작업 한 코드가 "사용되지 않음"경고를 받기 시작했습니다 ... 몇 개월 동안 비슷한 버전에 대해 이야기하고 있습니다. 번호).
내가 많이 잃었다 고 말할 수는 없지만 (이것은 개인 프로젝트였습니다) 가까운 장래에 Scala를 만지지 않을 것입니다. 그래도 여전히 매우 훌륭하고 유망한 언어라고 생각합니다.
내가 그랬을 때 10, 아버지는 저를 위해 새 해 노래를 연주 해 주셨습니다 Elektronika BK-0010-01.
말할 필요도없이 신디사이저가 테이프에서로드되지 않았고 이웃이 기타를 들고 올 때까지 노래가 없었습니다.
네, 있어요! JSF 1.0으로! Sun은 그것을 공개하기 전에 그것을 잘 검토하지 않은 것 같습니다.
우리는 일을 작동 시키려고 노력했지만 얼마 지나지 않아 JSF 버그로 인해 오류가 발생한 것을 발견했고 해결 방법을 사용해야했습니다. 프로젝트가 약간의 속도를 내기 시작한 것은 JSF 1.1과 myfaces-tomahawk 구현을 사용하기 전까지는 아니 었습니다.
QBASIC은 결코 성공하지 못했습니다. 나는 그것을 배우는데 수년을 보냈다.
좋아요, 공평하게 말하면 그것은 제 모국어 였고 배우는 좋은 방법이었습니다. 그리고 나중에 Visual Basic, VB.NET으로 대체되었습니다. 그래서 그것은 내 시간의 완전한 낭비가 아니 었습니다. ;)
대부분의 경우 언어가 정확히 "이륙"하지 않더라도 다른 것에 적용 할 수있는 좋은 학습 경험입니다.
Delphi.NET. 내가 들었을 때 여전히 틱이 있습니다!
최악의 경우는 새 제품을 사용하는 프로젝트를 통해 80 %를 얻고 눈에 띄는 버그에 부딪혔을 때입니다.
80 년대 중반에 제 상사는 KnowledgeMan이라는 새로운 dBase 대안을 시도해 볼 것을 제안했습니다. 내가 내 것이라고 생각한 몇 가지 중요한 버그가 실제로는 그들의 것임을 깨달았을 때가 멀었습니다. 모든 것은 처음부터 다시해야했습니다. 제 직업을 잃었습니다.
예. 저는 Lisp 프로그래머입니다. 모든 것이 새롭고 미숙 해 보입니다. :-)
AzMan (Microsoft Authorization Manager)
우리는 싱글 사인온에 대한 꿈과 "기존 인프라를 활용"할 수 있다는 주장 또는 현재 마케팅이 말하는 모든 내용에 따라 공개 웹 사이트 / 웹 앱에서이를 사용하기 시작했습니다. 시스템 관리자가 도구를 개발하거나 코드를 작성하지 않고도 관리 할 수있는 ASP.NET 용 드롭 인 솔루션입니다. 윈윈 이었죠?
우리는 결정의 결과로 몇 가지를 배웠지 만, 그중 어느 것도 배우고 싶지 않았습니다.
Active Directory 자체는 공용 웹 사이트를 서비스하는 인증 메커니즘에 적합하지 않습니다. 능력이 없다는 것이 아니라 매우 능력이 있지만 "Hello World"앱을 작성하기 위해 박사 학위를 고용하는 것과 같습니다. 그것은 그렇습니다, 자격 과잉있어 방법을 당신이 이제까지와 같은 컨텍스트에 필요한 수보다 더 많은, 그건 많은 일반 오래된 SQL 테이블 이상으로 작업을 더욱 어렵게하고, 필요 훨씬 더 유지 보수를.
AzMan은 느립니다. 아주 천천히. 역할 제공자는 캐시 를 유지 해야하며, 이는 우리가 말하는 성능의 종류를 알려줍니다. 나는 그것이 왜 그렇게 느린 지 완전히 이해하지 못했지만 그것이 의존하는 호넷의 COM 및 네트워크 프로토콜과 관련이 있다고 생각합니다.
캐시 (위 참조)는 제어 할 수없는 경우 매우 위험 할 수 있습니다. 새 사용자를 수동으로 추가하면 (즉, 사이트 자체가 아닌 관리 응용 프로그램을 통해) 해당 사용자는 캐시가 만료되고 로그 아웃 될 때까지 "권한이없는"화면이 표시됩니다. 때때로 이것은 온라인에서 자체 등록한 사용자에게도 발생합니다. 우리는 이유를 알지 못했습니다.
도구는 끔찍했습니다. 테이크 아즈 콘솔에서 간단한 모양을 당신이 날 믿어, 또는 일부 읽을 수없는 경우 문서를 당신이 정말로 두통을합니다. 왜 그렇게 복잡해야합니까?
색다른 것이었다. 많은 경우 공급자가 작동을 멈추고 비밀 COM 오류 (매번 다른 오류!)를 토해내고 IIS가 다시 작동하도록하려면 IIS 또는 전체 웹 서버를 다시 시작해야했습니다. 또한 도메인 트러스트를 설정했습니다. 내부 회사 도메인에서 50,000 개의 공용 사용자 계정을 원하지 않았기 때문입니다. 유일한 문제는 콘솔이 실패하기 때문에 역할을 관리 하기 위해 관리자 가 보조 도메인의 관리 계정 에 로그인해야한다는 것입니다. 기본 (보조 도메인에 대한 도메인 관리자 권한이있는 엔터프라이즈 관리자로도)에서 사용하려고하면 신비한 방식으로.
지원이 거의 존재하지 않았습니다. 기본 SQL Server 역할 공급자를 사용하는 경우 (그렇지 않지만 예로서) 1,000 만 개의 자습서가 있으며 Google에서 오류 메시지를 확인하거나 포럼에서 질문을 할 수 있습니다. AzMan에 문제가 생기거나 새로운 일을하고 싶을 때마다 좋은 정보를 찾기 위해 끊임없이 노력했습니다.
코드 통합이 어색했습니다. 복잡한 COM 레이어를 거쳐야했고 인터페이스가 엉망이었습니다. 내가 올바르게 기억한다면, 간단한 인증 확인을 할 방법이 없었습니다. 전체 앱 / 역할 레지스트리를 다운로드해야했습니다. 그러나 이것은 오래 전 일이므로 그 측면에서 내 기억이 흐려질 수 있습니다.
결국 우리는 더 이상 견딜 수 없었고 SQL Server 테이블 몇 개를 기반으로 자체 개발 한 시스템을 위해 전체 시스템을 추출하기로 결정했습니다. 아마 처음부터해야 할 일이었습니다. 마이그레이션은 고통 스러웠지만 (위의 두 가지 사항 참조) 우리는 그것을 완료했고 결코 뒤돌아 보지 않았습니다.
불행히도 그것은 두 가지 방법을 모두 잘라냅니다. Windows 용 대규모 웹 기반 앱을 처음 개발하기 시작했을 때 .NET은 곧 베타 버전으로 출시되었으며 .NET 1.0의 최종 릴리스는 얼마 지나지 않았습니다.
그러나 그것이 새로운 것이기 때문에 우리는 무슨 일이 일어날 지, 얼마나 인기가 있을지, MS가 6 개월 후에 그것을 떨어 뜨릴 지 여부를 알지 못했습니다. 그래서 우리는 검증 된 VB6을 고수했습니다.
우리는 여전히 VB6 레거시를 유지해야하며 한동안 제한적이었습니다. 어디에도 나열되어 있지는 않지만 주어진 Windows 버전에서 VB 런타임에 대한 지원이 철회 될 것이라는 편집증이 있습니다.
즉, .NET 경로를 사용하는 것은 그 자체로 고통을 겪었을 수 있습니다. 1.0, 1.1 및 2.0은 이전 버전과 (일부) 비 호환성으로 인해 서로 상당히 빠르게 나왔습니다. 따라서 .NET 플랫폼을 마이그레이션해야하는 것은 다른 위험을 수반했을 것입니다. 적거나 많습니까? 그것을 경험하지 않은 사람은 대답 할 수 없습니다 :-)
결국 그렇게하면 저주를받을 수 있고 그렇지 않으면 저주받을 수 있습니다. 누군가 주어진 기술이 한 번에 성공할 것인지를 결정하기 위해 내장을 읽을 수 있다면, 그들은 소프트웨어에서 직업을 가져서는 안되며, 대신 헤지 펀드 관리에 들어가야하고, 현금을 많이 벌고 일찍 은퇴해야합니다. -)
당근 빠따 지
나는 현재 Fortran 2003의 얼리 어답터가되는 고통을 느끼고 있습니다 :-)
표
Mozilla XULRunner.
AIR가 있기 전에는 Adobe AIR였습니다. 우리는 그것을 사용하여 인적 자원 관리 시스템을 작성했습니다. XULrunner가 FireFox의 기본 엔진으로 출시 될 예정 이었기 때문에 사용자가 FireFox를 설치했는지 확인하기 만하면됩니다.
2 years into the project, and right before deployment, a new XULrunner came out that completely broke all of our code, and a Firefox deployment was nowhere in sight. We ended up deploying on our older version with a dedicated desktop installer and have been using it ever since, without the benefit of security or performance updates because we would have to re-write too much code to be compatible. Despite that it has been a very successful project with our customers.
We're now re-writing the app to run on Ext which is the new hot thing for us but seems to have more community support, and offers commercial support if we really get stuck on something.
Java
I was very eager to start working on it in 1996 and used it for several projects. But for web development I always preferred Perl and these days PHP. GUI development I ended up mostly using .NET. For the few command line programs that cannot be handled by scripting I prefer to use Perl, Python or even for that PHP.
Few of the Java programs I wrote were used over long periods of time, while some of my pre-java applications are still in use.
I think the main reason for this is that it always took longer to develop something in Java than using another programming language: so the resulting applications contained less features and were easier to replace.
As speed of development is usually an issue for my customers Java tends to end up as the second choice.
I'm incredibly close to the flame everyday by being an early MonoTouch adopter. I never know what's going to happen next with this framework. But to its credit, the Novell team is standing by with fire extinguishers just about 24/7 :)
64 bit Carbon APIs on Mac OS X: I didn't get burnt personally on this, but I have a friend working for a big software company that spent a year converting almost all of their code to use the 64 bit Carbon APIs only to find out at WWDC that those APIs were no longer going to be made available.
Anyone noticed the trend here? The majority of technologies here were created and canceled or modified by microsoft...
I also have been burned by microsoft with changes made to the entity framework.
For lacking market presence:
- Google's Go
- Poor toolchain, lacks integration with popular compilers and C.
- Python3000
- Lacks must-have features: Iterators, cleaned up internals and tidier interfaces are nice for us hardcore users, but the majority want performance, and this hasn't been delivered.
- C++0x
- C99
- It's been 12 years, and no mainstream compilers fully implement this. Popular projects and niche architectures remain on C89 to be safe.
For poor quality:
- Windows Vista
- 'Nuff said.
- Perforce
- C++
For lagging behind upstream:
- PyGTK on Windows
- MSVC C support
Note that my listing these technologies in no way suggests that they're no good, I'm a huge fan of all of these (except the poor quality ones). My opinion on being burned by these technologies is first hand (usually me trying to push them as replacements for existing technology, or simply running into barriers after a significant investment has already been made.
In my opinion however, it is crucial for success in software industry to keep the pace with the innovation.
This doesn't answer your specific question, but, there's a book called Crossing the Chasm that might interest you.
I was once forced to used witango, but I'm getting over it.
For me Delphi's IntraWeb was it.
Not programming but still a newer technology blunder - I nearly lost a nipple to my first mini-ATX build, moral of that story is to never lean over a case while trying to forcefully close it when it gets jammed...
I could count many of them. The one that still hurts when I think about it is WLPI (an old BEA workflow product). Never worked out and the vendor abandoned it. Sigh ...
Anyway, I would say keeping up with the latest (knowing what is there, considering it) is very worthwhile, but only live on the cutting edge if:
- You are prepared to get cut and bleed (money/time/resources)
- It provides an important strategic advantage/competitiveness.
A good example for this is AJAX. It is now mature enough that every new website should be doing it unless they have a compelling reason not to, but when it was first becoming possible, a website built on it would have been very expensive compared to the traditional alternative.
Some websites need the latest look and feel to stay competitive, even to the point where the features of the site themselves are secondary and they needed to be AJAX early adapters. Others do not. Know who which one you are and act accordingly.
Blackbird.
A wonderful development environment for creating interactive content for MSN.
True Basic
In the mid-1980s we were looking for a development platform that would work on the various DOS implementations and not be as "bit-twiddling" a language as C was.
We found True Basic, advertised as having been created by the original creators of BASIC back in 1964. Here was a language that 'compiled' down to p-code. Not only would it run on DOS machines, it ran on GEM (Atari-ST) and Amiga boxes.
It had add-ons much like we were used to having with development environments on the VAX/VMS machines we used. Things like Forms packages, an "ISAM" add-on (before the days of callable databases on PCs), etc.
Unfortunately, the multi-platform abilities never sold the language enough. Heck, according to Wikipedia, there's a Mac OS version (though not OS X or Snow Leopard). I even found the 'current' TrueBasic page while writing this note.
Eventually Visual Basic 1.0 came out and all the BASIC programmer, like myself, checked it out since it had Microsoft's name on it. Now, of course, 10 versions later, we've been steered over to the .Net platform while TrueBasic sits at V5.5.
VBA - We spent a lot of time integrating it into our product. We still spend a lot of time on each new release to make sure that we don't break anything. VB6 and VBA is also COM based and that is a problem if you want to run as a standard user and not have write access to the registry.
This addresses your discussion more than your question. I think you are assuming that the cost benefit of adopting new technologies is a given. For a very large corporation, changing technologies can cost hundreds of millions of dollars. If the cost benefit is not there then the hundreds of millions can be saved. Most companies use technology to make something else and can not afford to consume new technology simply because it exists. When the cost benefit is there, then it makes sense to do so.
The TurboGears web framework
I had a web app to write and jumped onto this (having heard about it from a friend). I wasn't really aware of the alternatives, didn't know MVC properly and wasn't aware of the alternatives to the various 'standard' components (eg. SQLAlchemy instead of SQLObject). While the documentation and general state of the project is far better than it was when I got my hands dirty, I ended up with a huge application that relied on 'tricks' to bypass some of the magic features and had lots of undocumented features in it to meet the deadlines. It became a maintenance nightmare and I really wish I had taken the time to build something simpler with plans for a rewrite if the requirements changed.
This was 1.x series which has been deprecated now for the Pylons based 2.x series. As you can imagine, the core team itself decided on a rearch but I was stuck with a legacy application which I had to maintain.
ReferenceURL : https://stackoverflow.com/questions/904238/have-you-ever-burned-your-hands-by-some-new-and-immature-technology
'programing tip' 카테고리의 다른 글
| 여러 인수 중 하나를 사용하여 메서드가 호출되었음을 확인 (0) | 2021.01.09 |
|---|---|
| C ++ 템플릿은 단지 매크로 일 뿐입니 까? (0) | 2021.01.09 |
| 모달보기 컨트롤러의 iPad 사용자 정의 크기 (0) | 2021.01.09 |
| Cakephp에 대한 완전한 현재 URL을 얻는 방법 (0) | 2021.01.09 |
| LINQ를 통해 시간없이 DateTime을 비교하는 방법은 무엇입니까? (0) | 2021.01.09 |