Tech IT Easy » Amazon

e-Reader or Print Media which is Greener? Join the Debate…..

Anand — Tue, 09 Feb 2010 17:27:17 +0000

We have been reading postings and briefings on all sorts of touch pads and e-Reader recently, be it the Amazon Kindle or much disputed Apple’s iPad. But apart from usability and innovation involved in developing the product one feature that inspired me to write this post is its long term affect on existing Carbon Di Oxide emissions when adopted and accepted globally.

I still wonder if in a hypothetical scenario when every book and publication is digitized into an e-book and every reader only uses his gadgets to read the digital content instead of having a printed version on a paper. Will this be a much Greener situation to one we have right now? There are views and opinions prevalent in media which are more of equivocal nature. E-readers aren’t typically marketed as environmentally sound, but their environmental impact is now becoming a topic of discussion and research.

Point of Views : Expert’s View on e-Readers

At least Don Carli doesn’t thinks so, according to him e-Readers aren’t Greener than print (which is a common view held by consumers who don’t know the backstory of evolution of an e-Reader ). Actually few days back I had an opportunity to read an interview with Don Carli on News Media Innovation, Convergence and Sustainability.

As far as print media is concerned it could do a better job of managing the sustainability of its supply chains and waste streams, but it’s a misguided notion to assume that digital media is categorically greener. Computers, eReaders and cell phones all have a cost of operation, cost of manufacturing and cost of disposal. When Compared directly to the book, a Kindle produces 168 kilograms of carbon dioxide compared to 7.46 kilograms for a book.

Making a computer typically requires the mining and refining of dozens of minerals and metals including gold, silver and palladium as well as extensive use of plastics and hydrocarbon solvents. To function, digital devices require a constant flow of electrons that predominately come from the combustion of coal, and at the end of their all-too-short useful lives electronics have become the single largest stream of toxic waste created by man. Until recently there was little if any voluntary disclosure of the lifecycle “backstory” of digital media.

Point of Views : CleanTech Research based on Scientific Evidences.

Another interesting survey report from CleanTech Group which published the report based on life cycle analysis of a Kindle e-Reader. The research and media company drew on existing studies to do a lifecycle analysis and found that the carbon emissions from electronic books are far lower than traditional book publishing.

As reported in the analysis, “The roughly 168 kg of CO2 produced throughout the Kindle’s lifecycle is a clear winner against the potential savings: 1,074 kg of CO2 if replacing three books a month for four years; and up to 26,098 kg of CO2 when used to the fullest capacity of the Kindle DX. Less-frequent readers attracted by decreasing prices still can break even at 22.5 books over the life of the device,”.

Finding a conclusion to this article seems difficult:

eReaders are capturing media attention and there appears to be significant latent demand for gadgets that can replace printed media, but mainstream adoption still remains years away. E-reader device sales and eReader content revenues are still rounding error in relation to print media revenues. In a survey of attendees at this year’s Frankfurt Book Fair 40% predicted digital book content sales would overtake traditional printed book sales by 2018, but over 30% said digital content would never surpass traditional books sales, and 66% said they expect traditional books to dominate the market for the next decade.

With universities like Princeton and six others already testing the technology in a pilot, I hope e-Readers will make their way to schools and workplaces replacing traditional paper books. Ultimately, it comes down to how an e-reader is used. If a person continues to buy books and print periodicals and doesn’t recycle the product, the environmental impact could potentially be negative.

Getting hired by Amazon, Apple, …, Yahoo, ZDnet: tips and future hacks.

Georgia Psyllidou — Wed, 06 Feb 2008 01:05:29 +0000

Trying to digest a cheesy crust pizza this noon, I was wondering if instead of a pizza I was carrying a baby. The good thing was that there would be two of us going back to work, even if the one was rather unqualified to give me hand. What a delight for my pizzababy to grow mentally through this early job! Apart from hanging around with Bruckner’s twins (le Divin Enfant) getting early to work will permit it to develop the working flexibility that parents preannounce and corporations tend to establish through rotation programs.

So, how often will it switch jobs? Every 3 years, two times a year, each month or…. why not several times a day?

Assumption: A job may less and less be outline of your style, status and skills, THE choice that you make in your self-creative youth and pursue with passion until your hands have shrunk and you mumble wisdoms on professional resilience to your children.

It seems (to me, to you too maybe?) that jobs get more and more project–centric, existing-skills based, time and locality indifferent.

with Theme-generated-tasks’ accomplishment transforming into task accomplishment around a theme.

The digital business field, where change is well in advance, brings up a strong trend on segmentation of the classical notion of job.

Two examples on the internet can tell the story:

Amazon’s Mechanical Turk

and

Innocentive

These two companies propose a per task remunerated employment, amazingly different as regarding necessary skills.

Amazon’s Mechanical Turk mostly addresses the non qualified workforce and Innocentive the ultra specialized scientific one. The concept on both is that you’re hired on a per project basis, for a translation, to prove the Fermat Theorem or to fill in the ISO forms.

It is then highly important to have a personal job management system to handle contests you participate and your prizes, puzzle your profile and communicate with trusted professionals.

A sort of e-mployment survival kit to prevent you from e-xploitation.

This vast talent pool of potential Mechanical Turks, scientists and everyone between, also creates opportunities for providers of meta-HR services to aggregate and compose job particles into a real job.

Providers such as advisors, agents and therapists:

social engineers, serial trendsetters, legal timing planners for fringe technology testers (“get the trial before the action is criminalised with a law”), real life rehabilitation mentors (“get rid of Wii gestures when in the grocer’s”), tec-addiction therapists, viral marketing therapists/ digital image makers (banal already maybe), mini-krach recoverers, startup estate agents, other (attention, this is not a generic term, it can be a job where you are paid to differentiate and foster evolution), and so on.

A combination of a middlejob with a classical one or the mix of various middlejobs could result in a steady plus variable income, mental coherence and growth, an optimised planning and a life-job balance.

On the “which?” the question is open. On the “how many?” 2 jobs maybe ok while 3 or more could definitely assure the statics of the e-mployement construction. …

Job- memo for my pizzababy: Exercise with 3 or more jobs, with an hourly basis frequency, vary the status. In case you need help call your agent.

After it was digested I went back to work.

Georgia

Unlike

High Availability Architectures (3/4) – Performances

ceciiil — Thu, 08 Nov 2007 08:31:25 +0000

In the previous posts of this serie we’ve addressed the availability and scalability aspects of high availability systems. In this (rather lengthy) one we’ll focus on the performance side of things.

Again, performance is something to be contextually defined quite early in the project. For instance a requirement such as “3s response time” is not precise enough. “3s response time with 200 simultaneous users” is a valid requirement.

History

Performance has been a common issue for the last decade or so with the emergence of multi-tier IT systems. It has not been such a problem in the past or rather it has been addressed as the core issue and fixed once for all during the mainframe years (65-89). It also has been skipped during the client-servers years (90’s) as no real software architecture was in place. Back then, no-one would react if SQL code was found in the presentation layer.

Nowadays, the standard 5 layer software architecture (Client, Application, Business, Integration and Resources) has naturally emerged as the de facto solution. The basic principle is to ensure for isolation between layers to provide the software architecture with a greater modularity and robustness. With the considerable litterature available, architecture software development constraints are much more pregnant – and that’s an excellent thing.

However, such complex software architecture requires to be extremely cautious from the very early stage of architecture and design as a laidback appoach can prove to be quite expensive in terms of performance.

Usual Suspects

From experience, when it comes to performance, the usual suspects in this 5 layers architecture are :

Integration tier
Database tier : Execution plans, indexes, table schemes, DBA early in the process
Business and Application tier : Algorithm, transactions, resource connections and APIs

Integration tier

Java Enterprise frameworks (Hibernate, Entity Beans) have been developed to abstract data persistence from the application developer. On one hand that’s a good thing : application developers can then focus on their own business problems and forget about SQL.

As a result these frameworks usage may not optimised and it could happen that application developers lose control on what they actually do, the number of objects in memory etc … The solution is to keep a fine grained control on these frameworks and the SQL that is actually generated and executed behind the scene. A close collaboration with a experience DBA (Database Administrator) is strongly recommended here, from the early steps of design.

For information, it’s worth mentionning that big internet giant such as Amazon for instance just don’t use such frameworks in order not to lose control on piece of processing that actually is critical in terms of performance. Read this article on that very subject.

Databases tier

Another drawback is that SQL not being at the center of development concerns, we may end up with applications that are not really optimised from the database perspective : database schema and queries execution plans are inappropriate and inefficient.

Then again it is recommended to have a DBA involved from the very early stage of the project (architecture and design) to validate the database schema and suggest execution plan to optimise the database usage.

Stored Procedures

At first, stored procedures may be considered as antiquities inheritated from the client/server years, souding like heretic software components from the 5 layer perspective.

However, from a genuine performance perspective they still are top drawer solutions. Data handling on the server allow to save a lot of time for applications and on the network.

The aim here is obviously not to develop the whole business layer as sored procedures but, rather, to optimise a few heavy process. Besides it proves to be an excellent antidote to the “DB request machin-gun” anti-pattern.

Application and business tier

There are a few standards Java dos and don’t to improve algorithm path length and CPU/memory usage.

The most important ones though regard sessions, transactions, APIs and resource connection

Avoid stateful component whenever possible (EJB Stateful sessions are performance killers). Whenever handling sessions (e.g HTTP Session) make sure they don’t contains too many objects.
Transactions must be kept as short as possible.
Resource connections are very precious asset. There use should be optimised to the actual need and kept as short as possible.
Whenever developing services API, always develop both unitary treatment service (i.e perform one action for one given item) and multiple treatments interface (i.e execute multiple request with multiple inputs and return multiple replies). This basic principle allows to save a lot of time by avoiding machin-gun request to the service.

Lastly, whenever building a new enterprise system using platform such as JEE or .Net, we need to keep in mind that these were made for real time process, not for long process. So if the application you are developing takes times (i.e above 5 sec), this component must not be deployed on the application server : it will uses precious resources for long process that are not used in the meatime to serve real-time services. Such a component should be deployed as a stand-alone server instead.

The Asynchronous trick

This is a great tool to load balance. Whenever addressing long process issue, it always is worth considering deploying it as an asynchonous service. This is a very natural and elegant load balancer mechanism that does not impact real time service QOS.

The biggest problem here is to convinced the business to accept to implement some asynchronous solution for rather peripheral services (e.g Reporting).

JMS is the natural solution whenever developing asynchronous solution in the Java world. One has still to be careful when choosing a JMS implementation.

A basic rule of thumb is that whenever you’re dealing with transactional messages with high availability and robustness concerns, you should rule out JMS implementation without persistence mechanism. JBoss JMS for instance is not as mature as JBoss Servlet or EJB implementation. Today the best solution on the market for JMS is SonicMQ.

Unlike