Site Sponsors:
Technical Staff Ascessments - Good or Evil? 
I make my living training & consulting on extremely technical topics. One would think that I would want everyone in the world have their technical staff analyzed. -Yet, when the topic came up linked-in recently, a sense of enlightened self-interest - rather than brutal-self interest - simply had to take over.

I thought I would share my answer here.

Question: "How important is it for companies to conduct staff technology assessments?"

Response: "The question should be asked, why does anyone feel the need to conduct a staff technology assessment?

If one is looking to to train, then doing so just might barely be a good idea - but why not just ask them what type of training they want, instead? If one is looking to judge others as static quantities, then doing so can be not only offensive and / or intimidating, but almost evil. Why? Because people are dynamic. People can learn. Ultimately, no one likes to be judged.

So the answer is: The value of whole-staff technology assessments depends upon the intent behind them. If one is motivated to help someone to learn technology & become better... or not.

In general, in tough economic times such as these, at a minimum I would say that it is a very bad idea simply for reasons of morale. Indeed, if one is looking to better their staff, simply anonymously ask if they would like any technology training - find the critical mass - then train them in topically-sorted order?"

More Ideas


We should resist the idea of people even keeping records of previous test scores. Why? Because what one did not know then, one can certainly master, today. Moreover, even if one is prepared to keep track and re-take every test one has ever taken, old-scores will still be mentally used against someone for many, many years.

This problem of test-score permanence becomes even worse for Internet tests. --Who is going to expunge older test results from blogs (a celebrity’s pre-school tests), or Google?

Cleaning up Internet inertia may also bump First Amendment issues. (Unlike many elected representatives sworn to protect it (promise breakers?) I for one support the Constitution of the United States as one of the most inspired documents since the Magna Carta: If you are an American, then tell your Congressman that you do, too!)

So while exams are important, there are also good tests, as well as bad tests. Experts know that any single test score is of absolutely no importance unless a common class experience, in-depth student profiles (*), as well as a mode, median, and / or cross-test population mean - are also shared.

Hence, no mater the reason for giving any assessment. -In an age when even our governmental identifiers cannot be adequately protected by places whose very business depends upon data security, who wants the results of a 'bad test' forever stuck in any database... let alone forever 'searchable across a WORLD-wide web?


(*) Why student profiles? I recently tried to teach a batch of mixed-in welfare-to-work folks - who had neither the aptitude, nor desire - to learn how to program. Despite over 12 weeks of 10 - 12 hour days on my part, private mentoring by other company employees, and even successfully lobbing for company-gifted laptops to all, none of their number would even complete a handful of remedial exercises on-their-own.

Needless to say, while those of the class who had previous programming experience did well, for the rest - from cheating & legal threats, to outright character assassination & false-witness collusion - did not.

The experience was a perception-challenging exercise for all concerned. (i.e. While a well-documented part of a child's mental-recovery process, when the stakes are preconceived to be as high as one's entire financial future (not the case here - company said as much), even "Denial" fallout over test-taking results can be excruciatingly painful for any employer.)


[ view entry ] ( 3649 views )   |  permalink  |  related link
EzLog4J Updated - About Time Started 
One of the nice things about owning our own time is that, in-between bill-paying activities, one has the ability to make cool things for others to use.

For me, I am finding that the more busy I am, the more I need EzLog:



You can download the latest version from SourceForge.net here.

What's New


Note that a version of EzLog4J is morphing into a tool called "About Time." Before I split the product officially, I am making (mostly graphical) changes that both products will benefit from.

Going forward, in the future:

EzLog will be more about documenting what we work on every day. Best for Employees & Consultants.

About Time will be more about tracking the progression of multiple, overlapping, tasks. Better for Managers & Scientists.

So the new upload today is a toast raised to our busy-times ... as well as to those precious moments that we all have to create & share things with others.


Enjoy,

-Rn



[ view entry ] ( 1754 views )   |  permalink  |  related link
BEST - Web Services for the Rest of Us? 
In the world of computer technology - as everywhere else - there is Knowledge, and then there is Wisdom.

Of course, Knowledge is simply knowing something...

Wisdom ... where & when to use it?

Problem Domain


While SOAP & REST -based web services are great for folks with racks of servers & software developers, a very real need exists for those businesses who presently - having neither - yet wish to create programmable interfaces to those legacy, web-based, HTTP Services. (For the purposes of this white paper, we are considering anything from a simple page request (HTTP GET) to a web-hosted, fill-out-form (usually HTTP POST,) to be a legacy, or classically defined, web-service.)

Indeed, as the demand for mobilized application support increases, the need to quickly host cost-effective, legacy-integrated Web Services, is becoming far, far more important every day.

Next, even after one can programatically re-use their Internet legacies from a rapidly-developed & previously-deployed Web Service, the NEXT most important task is - since most are ever aspiring to become the next "big company" - to be confident that one can GROW such services into a set of enterprise-class, ESB capable, secured transactions.

The present, often excruciating need to (1) rapidly & affordably create Web Services into our present, Business HTTP Services, as well as to (2) grow them into Enterprise worthy solutions, is why we have taken the time to define B.E.S.T.

BEST Overview


Business / Enterprise State Transfer (BEST) is a set of architectural guidelines. Conceptually drawing heavily upon successful Internet data interchange patterns & practices, the main focus of BEST is to both embrace and extend classic client / server requests and responses.

Rather than abandoning decades of successful data processing activities, the canonical BEST Reference Model (BEST-RM) seeks to encapsulate & extend traditional Internet client / server operations so as to support modern, version controlled, Web Services.

BEST-RU


Central to the core of a BEST architectural approach is the concept of the Request / Response Unit. Traditionally referred to as an RU, most of the BEST-RM demonstratively builds upon decades-old networking concepts.

When viewed as a self-contained data-interchange pattern, the goal of defining the BEST RU as a stateless, session-less, transactional architecture unit embraces the main design principles of both SOA/SOAP and SOA/REST.

Indeed, while a BEST-RU need not be stateless, widespread recognition of the scalability, maintainability, and robust nature of transactional processing systems are well documented.

Security


Another very real benefit of evolving state-bound requests & responses into far more stateless choreographies might be to apply a higher degree of design rigour. Indeed, once we acknowledge that designing-in support for stateless data representations can indeed provide all-in-one cyphers to would be system attackers, the practice of defining multiple RU's to provide data to any single business operation should be considered a security best-practice. -In many ways, providing support for multiple, varying RU encodings is merely a simple extension of proper RU / Service Version Control.

RU Service Concepts


The next best practice suggestion is - when not otherwise implied by a service legacy – that any and all operational requests simply be relocated into the body of the RU.

Indeed, while CREATE, READ, UPDATE, and DELETE (CRUD) operational requests are well documented, requests for SEARCH, SERVICE STATUS, SERVICE EXCEPTION, ROLLBACK / COMMIT, LOGON / LOGOFF, and SERVICE AUTHORIZE / DEAUTHORIZE actions have also been considered traditional design requirements. Hence, when defining the content of any RU, the exclusive, unary, operational nature of each anticipated service-request demands that each sibling operation be defined in the exact same place. (i.e. Avoiding present or future operation-state confusion and / or collisions is also an important part of a rational RU Maintenance Policy.)

BEST-RM


When viewed as a set of self-contained, stateless, version-controlled datagrams, the definition of the canonical BEST-RU easily embraces the classical Internet data exchange model. BEST does not require legacy servers to implement hitherto unnecessary HTTP Operations (such as PUT and DELETE.)

Implicit Version Control


Indeed, once the ostensible, legacy, service-oriented operational intent of a classic GET / POST request is understood to be merely a "1.0 Service Contract", then very little imagination is required to appreciate how every existing HTTP Request can be considered to be a BEST-RU.

Thereafter, and again when not otherwise implied by a much wider service legacy, we must merely note that any future operational requests must also be encoded into the body of the RU. Thereafter, just as when evolving any other service definition forward, a unique RU and / or Service Version identifier should be provided.

Protocol Neutrality


Another practical effect of moving operational requests into the next version of an RU not only allows for the continued operation of classic GET / POST client / server operations (hidden form fields, etc.), but also supports many other RU delivery techniques, as well. -Either one, or a series of BEST-RUs can be stored & forwarded in everything from disk-files & USB devices, to regression-testing tools & frameworks.

Clearly, in as much as legacy HTTP/S Forms & Services can continue to be supported by BEST-RM Web Service (BEST-WS), even real-time, production-level diagnostics can continue to take place using traditional, browser-based interfaces. No special web-service testing tools will be required.

Finally, we might note that adopting a self contained, BEST-Oriented, transactional mindset not only extends our service operations far outside of the HTTP protocol, but also prepares an RU for operation across such modern processing platforms as the Enterprise Service Bus (ESB.)

Conclusion


Ultimately, when adopting a BEST Approach, the mature, natural, and rational requirement to embrace existing, as well as future, RU-submission techniques encourages a more evolutionarily, incremental, enterprise-worthy, & economical adoption of Modern Web Services.

Elevator Pitch?


At some point in time, we need to relate the technical advantages of BEST in such a was so that even a PHD laureate might understand them?

In the mean time, from a completely business vantage-point, simply understand that, unlike REST, rather than:

(1) Updating / discarding traditional HTTP Servers

(2) Hiring an army of software developers to support hitherto unnecessary HTTP Operations

(3) Breaking legacy browser-based services

(4) Alienating popular server-side technologies (such as PHP)

(5) Re-writing legacy server-side Service Providers

(6) Introducing latencies as a service request is re-encoded

(7) Translating HTTP requests to make sense elsewhere

(8) Relying EXCLUSIVELY upon any single protocol (HTTP/S)

(9) Multiplying the number of RUs flowing throughout the enterprise for any single request

-The BEST-RM simply:

(1) Moves operational service-requests into the RU when not otherwise implied

(2) Assumes an un-versioned request is for the legacy service

(3) Allows any BEST-RUs to be submitted to any BEST Application-Service (classic transaction processing is an ESB Pattern.)

(4) Assumes the existence of Input, Output, and Error Reporting Processing for each and every BEST-RU

(5) Improves transactional monitoring, accountability, & traceability (1 end-to-end RU for the entire service operation)

(6) Can both encapsulate & deliver Classic HTTP/HTML, SOA/SOAP, SOA/REST and / or any other type of service requests.

Everything else should be able to be appreciated by anyone who understands the way the Internet has operated for the last 20-odd years.

Postscript


It is hoped that the above discussion is enough to support your attempts to more economically & rationally embrace, encapsulate, & extend your present service legacies.

Please note that I plan to add more diagrams, discussions, and BEST-RM walk-thrus as time permits.

In the mean time, the reader might wish to refer to the original post.


[ view entry ] ( 3674 views )   |  permalink  |  related link

<<First <Back | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | Next> Last>>