Java for Programmers

By Paul J. Deitel, Harvey M. Deitel

* Publisher: Prentice Hall PTR
* Number Of Pages: 1200
* Publication Date: 2009-02-12
* ISBN-10 / ASIN: 0137001290
* ISBN-13 / EAN: 9780137001293

Product Description:
PRACTICAL, EXAMPLE-RICH COVERAGE OF:
* Classes, Objects, Encapsulation, Inheritance, Polymorphism, Interfaces, Nested Classes
* Integrated OOP Case Studies: Time, GradeBook, Employee
* Industrial-Strength, 95-Page OOD/UML® 2 ATM Case Study
* JavaServer™ Faces, Ajax-Enabled Web Applications, Web Services, Networking
* JDBC™, SQL, Java DB, MySQL®
* Threads and the Concurrency APIs
* I/O, Types, Control Statements, Methods
* Arrays, Generics, Collections
* Exception Handling, Files
* GUI, Graphics, GroupLayout, JDIC
* Using the Debugger and the API Docs
* …
The practicing programmer’s DEITEL® guide to Java™ development and the Powerful Java™ Platform
Written for programmers with a background in high-level language programming, this book applies the Deitel signature live-code approach to teaching programming and explores the Java language and Java APIs in depth. The book presents the concepts in the context of fully tested programs, complete with syntax shading, code highlighting, line-by-line code descriptions and program outputs. The book features 220 Java applications with over 18,000 lines of proven Java code, and hundreds of tips that will help you build robust applications.
Start with an introduction to Java using an early classes and objects approach, then rapidly move on to more advanced topics, including GUI, graphics, exception handling, generics, collections, JDBC™, web-application development with JavaServer™ Faces, web services and more. You’ll enjoy the Deitels’ classic treatment of object-oriented programming and the OOD/UML® ATM case study, including a complete Java implementation. When you’re finished, you’ll have everything you need to build object-oriented Java applications.
The DEITEL® Developer Series is designed for practicing programmers. The series presents focused treatments of emerging technologies, including Java™, C++, .NET, web services, Internet and web development and more.

Ebook(PDF) | Paperback on Amazon

Webhooks. User-defined callbacks on the web. Yes. YES! Wait, what does that even mean? That stupid website doesn’t seem to explain them at all!

Let’s explore this through an analogy. This analogy uses stockbrokers! Yay! (?)

Consider, before the web, before email, how people would interact with their stockbroker: the telephone. Whenever you wanted to manage your investments and find out what’s really going on in the market, you would call your stockbroker. It’s similar to how you might use your browser to visit Twitter to update your status and find out what’s going on with your friends, right? This is the basis of the analogy. Bear with me.

Imagine in this story your phone is a browser, a phone call is a web request, and the broker is a web application, like Twitter.

It’s 1989 and you like to think of yourself as a big time stock trader with an impressive portfolio. Good for you. You got to this point by staying in close touch with your stockbroker. You’d call her (!) to find out what was happening in the market, discuss whether buying certain stock was a good idea, and maybe put in an order. You were able to get information out of the system and put orders into the system by picking up your phone and calling your broker.

The problem is that you can only react to events in the market as quickly as you get the information. This means you’d have to call your broker quite a bit to stay on top of a fast moving, highly volatile market. A programmer might try to automate this with a script. You take a similar approach: you hire an assistant to deal with your stockbroker. Perhaps this is unheard of in reality, but stay with me.

Now an assistant is not unlike a computer program in theory. You can give them instructions and based on certain conditions and input, they’ll do as you say. For example, maybe you instruct your assistant to buy a certain type of stock after it behaves a certain way, and if there’s not enough money to buy the amount that you told them, they can transfer the money from your savings account after a quick confirmation phone call with you. In today’s world, that sort of thing is not terribly out of the question to automate with a script using the web APIs and programmatic infrastructure available to us now.

Again, in order to react to events in the market in a timely manner, it requires lots of phone calls to your stockbroker. Sure, your assistant can handle it, but it’s a lot of work and wastes a lot of time. In fact, it wastes you money because you pay for your assistant by the hour! If you were a programmer, your script would have to constantly poll the broker API requiring a touchy cron setup or a long running process that gets more inefficient the closer to real-time you want it to be. Not to mention it’s just more work than you should have to deal with. If only there was some way for your assistant or script to be notified when things happen so they could simply react.

One day, your stockbroker says they’re providing a new service they describe as callbacks. You give them a phone number, and they’ll call it whenever something interesting happens regarding stocks relevant to you. Wow! Well, you could give them your number, but there are two problems. First, it’s 1989 and you don’t happen to have a cell phone. You can’t always be reached. Second, even if you could, you’d still want your assistant to handle the events because they have been instructed with how to deal with them and will do a lot of the legwork for you. Luckily, your assistant has a cell phone and is always available, so you give the broker their number.

Now your assistant is working very efficiently making you lots of money. Their job is so much easier because they don’t have to do anything until they get a call from either you or, more importantly, the broker. They can finally react to events as they happen, without a lot of nonsense trying to stay on top of things. What’s more is they will automatically take care of whatever situations you’ve told them.

What a cool feature, this callbacks thing. Thanks, broker!

If you haven’t guessed, the callback feature in this story is the exact mechanics of webhooks. Webhooks would allow you to tell the web apps that you use to “callback” scripts you have online. These scripts will deal with whatever events that web app produces. These callbacks use the same protocol you use to talk to them and that you both know how to use: web requests. Putting your script online at a URL is analogous to your assistant that has a cell phone: it’s always available for direct connection at a persistent “phone number,” unlike you, with dynamic IPs and NATs and turning off your computer. And just like an assistant, the script can do a lot of interesting things for you that you wouldn’t necessarily want to do, most of which is a sort glue work of making different systems work together given some logic. For example, transferring money from your savings account to the broker account when there isn’t enough.

A concrete example of a story made possible from webhooks that might be a useful scenario for many of you involves Twitter. Let’s say Twitter supported webhook callbacks for when somebody follows you. Right now you get an email, and from there you can decide what to do manually: follow them back, block them, or do nothing. I used to go out of my way to block users that I knew were spam bots, but now there’s so many it’s not worth the time. And of course I also generally follow back people that I actually know. If Twitter would simply call a script of mine whenever somebody followed me passing along the user ID, I could very easily run this logic in a PHP script or a simple App Engine app. Or perhaps I’d use Scriptlets (ahem, which was made exactly for these kinds of web scripts). It would work like this:

First, use the Twitter API to look up the user from the ID, and grab their name. Then use the Facebook API to check if that name shows up in my list of friends on Facebook. If so, use the Twitter API to follow them back. Otherwise, if they’re following over 1000 users and that number is more than twice the number that’s following them (which is roughly the heuristic I use manually), use the Twitter API to block them. All automatic.

If you could do this, not only would you have glued together Facebook and Twitter in an interesting and useful way, but you’ve sort of extended the net functionality Twitter provides you. You could imagine perhaps someday Twitter releasing features that would do exactly what you just did. But they won’t. In fact, they’ll never release features that are so specific to you (who says my spam algorithm is the algorithm everybody should use?). This is how webhooks make the web more about you. You can start extending web applications and gluing them together just the way you want.

This is a win-win for web application users and developers. Users get more functionality. Developers can implement less.

Coming back to the stockbroker analogy, there is a type of order called a limit order where you say to buy or sell when it’s at a certain price. With webhooks (or the broker “callback” service), this is merely a convenience because you could easily set that up outside of their system. Speaking of that example, when I mentioned your assistant transferring money between accounts, that reminds me, you know that feature banks have called overdraft protection? If banks had webhooks, all banks could have overdraft protection. Wow, right? That would have been nice for me when I had Washington Mutual, a bank known for its lack of overdraft protection.

What else could you do in a world with webhooks? Basically everything would have a common event-driven infrastructure, allowing you, with just a little bit of scripting glue, to accomplish so much more and make the systems you use better, and more personal.

Application Programming Interface are interfaces that a program implements in order to allow other programs to interact with it.

In den Achzigern und heute

Andere schreiben Ihre Memoiren. Das ist mir noch ein bißchen zu früh. Aber als mir vor kurzem durch den Kopf schoß, daß ich heuer seit 25 Jahren mit Nikon-Kameras arbeite, da wurde mir auch bewußt, daß ich natürlich und selbstverständlich dann auch bereits ein Vierteljahrhundert als Bildjournalist auf dem Buckel habe.

Na gut, dachte ich mir, jetzt hast du schon einen Film über deine ganzen “alten Hobel” gemacht, dann mach doch noch einen, fass’ mal zwei Jahrzehnte in zweieinhalb Minuten zusammen.  Und dann such in deinem Halbmillionenbildarchiv doch einfach noch ein paar persönliche Bilder raus und mach doch einen launigen Artikel. Es gibt ja noch mehr als alte Kameras. Die “gute alte Zeit”, die kannte ja auch noch das Leuchtpult, das Dia, den Fotoabzug, Passepartouts, Slide-Sheets, äh, Diahüllen, Archiv-Regale, Archiv-Kästen, Acetathüllen für Prints und all solche Dinge.

Also bin ich nochmal in mein “Alt-Archiv” getigert und habe ein bißchen rumgewühlt. Hoffnungsloser Nostalgiker eben. Ach, und manchmal macht es doch auch einfach Spaß, in der eigenen Vergangenheit rumzukramen. Ich schau’ mir ja auch gerne Fotoalben an.

Da sind wir auch gleich an einem Punkt, warum jeder was von der Fotografie hat. Die Fotografie hält das Gedächtnis wach. Man erinnert sich an Orte und Ereignisse und kann sie sich auch visuell ins Gedächtnis zurückrufen. Ich sage immer “Ohne die Fotografie verlieren wir unsere Erinnerungen”. Ohne die Fotografie verblaßt irgendwann alles im Dunkel der Vergangenheit. Wir vergessen, wie Orte und Menschen ausgesehen haben. Wir brauchen Fotos, um die Erinnerung wachzuhalten.

Würden wir uns denn, könnten wir es überhaupt, an die unbeschreibliche Stimmung im November 1989 erinnern, an die Zeit vor 20 Jahren, als die Mauer fiel, wenn es davon keine Fotos und keine Filme gäbe? Wüßten spätere Generationen, wie das damals gewesen war?

Und, zugegebenermaßen, heute am Notebook, mit Memory-Cards in der digitalen SLR, mit FTP und Online-Bilddatenbank, würde ich nicht ab und an mal wieder einen Blick auf mein Leuchtpult werden, einen Abzug in die Hand nehmen (und überlegen, ob ich den nicht vielleicht mal einscannen sollte) oder ein paar Diahüllen, die Filmschnipselchen mit der Lupe auf Schärfe begutachten, man könnte ja irgendwann wirklich vergessen, wie man mal bis vor nicht allzu langer Zeit gearbeitet hat.

Und heute? Heute habe ich dank IrfanView den “elektronischen Kontaktbogen”. Ist das nicht toll? Den kann ich dann ausdrucken und mir ganz normal anschauen, so wie früher den mit den Filmstreifen drauf. Er hat aber auch einen Vorteil: den kann ich nicht nur ausgedruckt einer CD beilegen, die ich meinen Kunden schicke, den kann ich auch als E-Mail-Attachment verschicken und mein Kunde weiß dann, was ich Neues in der Datenbank habe.

Oder, wenn er, wie der oben, nun auch schon ein paar Jährchen alt ist, als “digitale Nostalgie” hier in einen Artikel packen. Neh, neh, Nostalgie ist was schönes, aber die digitale Welt hat schon so ihre Vorzüge. Was hatte ich früher zu tun, wenn ich einen Bildkatalog erstellen wollte. Das ist schon viel einfacher geworden. Und es ist ja nicht so, daß man sowas nicht mehr bräuchte. Und außerdem kann man sowas nun auch schön online machen.

Ach, apropos Online-Katalog:

1. Der Winter steht mal wieder vor der Tür
2. Winter in allen Facetten
3. Wetter ist immer
4. Und Weihnachten ist auch bald
5. Natürlich auch mit Weihnachtsstreß

Wer sich redaktionell, editoriell oder auch werblich, ob Print oder online, dafür interessiert, ist bei den beiden da unten im Bild bestens aufgehoben.  Wir produzieren nämlich nicht nur Ratgeber und Services zu Gartenthemen und der Gartensaison oder zu Naturthemen, sondern überhaupt zum Lauf der Jahreszeiten. Und noch zu vielem mehr.

Und heutzutage natürlich auch in digitaler Top-Qualität. Zu finden auch via APIS (i-picturemaxx) auf unserem Pool bei Mecom-Multimedia.

Unsere Preise und Leistungen. Und unsere Konditionen.

Ein Dreamteam: Irmgard und Franz Roth

Last but not least findet man unser Bildmaterial auch bei der Bildmaschine in der Datenbank und auch bei unseren – und da ist schon der kleine Schlenker zurück zum Ausgangspunkt – bei unseren traditionellen Vertriebspartnern und Bildagenturen, mit denen wir bereits nun auch seit zwei Jahrzehnten zusammenarbeiten, etwa Interfoto. Im Vertrieb dieser Münchner Agentur ist z.B. das Foto unten von dem Sportwagen mit Skiträger auf der verschneiten Gerlos-Paßstraße in Tirol.

Eines meiner Bilder im Vertrieb von Interfoto

Und apropos Auto: Da haben wir auch so einiges im Angebot (auch automobile Nostalgie und automobile Träume), bis auch hin zum Thema Verkehrsinfarkt. Der Traum vom Auto wie auch das Auto als Alptraum.

Zum Thema Auto beachten Sie bitte auch diese Posts:

1. Unsinn Abwrackprämie
2. Ende der Abwrackprämie

Ähnliche Artikel:

1. Jahrestage 2010
2. Der Fall der Mauer
3. Medienstadt Nürnberg
4. Fotografenalltag
5. Tools of the Past

I’ve had a rant building up for a few weeks. A rant about developer’s treatment at the hands of the App Store submission procedure. However unlike many rants on the topic, mine is not directed towards Apple (s aapl). It is directed towards the iPhone developers who complain about the poor, unfair treatment they get, carrying their bleeding hearts in their palms while claiming Apple is bludgeoning the life out of them.

Two recent news headlines, seemingly separate, are intrinsically tied together and the synergy of them have made my eyes dislocated from the continued rolling they involuntarily perform.

The first headline, Facebook Developer Turns Back on iPhone relates how another high-profile developer has thrown their hands up in disgust over how Apple’s closed system runs against their principles. A direct quote from Joe Hewitt, developer of the popular Facebook application can be found on TechCrunch, and is most relevant. I will come back to this later:

I respect their right to manage their platform however they want, however I am philosophically opposed to the existence of their review process.

The second headline is Apple’s App Store Approval Process Now Includes an Automated Layer. The quick version is that Apple is now using an automated tool to determine if the Apps that developers submit to the App Store are using any Private API calls.

These two headlines are actually the same story, a fact that was made quite apparent by a popular direct iPhone-to-iPhone messaging App called Ping!. On Ping!’s Facebook Page, the developer announced that the much-anticipated version 1.2 of Ping! has been rejected by Apple:

Bad news is Ping! 1.2 has been rejected by Apple on Nov 14 due to a software library we used, developed by the Facebook company. This library is used by many apps including Ping! and the iPhone Facebook app itself. Unfortunately the most recent version of this library has violated some of Apple’s guidelines and  has caused hundreds of apps to get rejected including Ping! 1.2.

So let’s get this straight. Ping! and hundreds of apps have been rejected because they used a popular development framework, a framework which used Private APIs. A framework, which was created by Joe Hewitt initially for use with the Facebook application and then made available to third-party developers.

Lets be clear about this; Joe Hewitt used Private APIs in his public framework, well-known to be against the rules of the App Store, and then acts all indigent when Apple slaps his framework down. Rather than disclosing his error, rather than saying “oops sorry about that,” he would rather ride the trendy wave of ‘blame Apple control policy’ and cite ‘philosophical differences.’ I rather wonder if these philosophical differences would still be present if his framework hadn’t been caught in this automated tool. If it were just other people’s frameworks that were caught, would he still have quit for ideological reasons?

Now I don’t mean to pick solely on Mr Hewitt, and maybe I’m being too harsh. But he is just the latest example in a blogosphere that increasingly seems to love taking the loud minority and say “Look! Here’s proof that the end is nigh!” Come on, the end isn’t nigh, it’s not even on the horizon. Out of the thousands of App Developers that exist, we’ve had a dozen, maybe two dozen make a public fuss and quit. Big deal! This is the real world; businesses start, some succeed and some can’t hack the brutal reality. Those just make excuses and quit. Just like everywhere else in the business world.

To summarize the full story that I see, it goes something like this:

• Apple publishes the rules for making iPhone Apps, including publishing and documenting the specific APIs which developers are allowed to use.
• Some developers ignore these rules and make use of Private APIs. Some Apps get through the cracks in the newly functioning App Store review procedures.
• Apple starts to crack down on private API usage. Developers who get rejected due to Private API use cry foul “Why are WE rejected but THOSE apps are allowed?” This was a fair question.
• In response Apple says “They shouldn’t have been allowed, we are working on a way to fill up the cracks in the system”
• Apple then goes ahead and fill the cracks with an automated (and thus unbiased) system to test of private API usage.
• Developers then cry foul, “It’s not fair, you’re a bully, it’s too hard.”

Cry me a river….

Before I get off my soap box, I’d like to add that there are times and places for Private API use. As a professional software developer working on proprietary custom embedded solutions on Windows Mobile devices for specific customers, I freely admit to using Private API calls at times. Sometimes its necessary to get a specific job done. The difference is scope and control. Our clients deploy the software under our care and guidance, with specific OS and hardware requirements. If they change devices or operating systems, we know about it well in advance and can prepare for it accordingly. Our clients don’t just upgrade the OS and expect everything to work.

The consumer market is a completely different kettle of fish, customers upgrade willy-nilly  and expect things to just work, especially things related to Apple products. Private APIs are private for a reason, because they can not be relied upon to behave from one OS release to the next. This means that applications will break and the consumers, you and me, lose out.

In the brutal competition of any market place, and indeed the world in general, the strong will survive and the weak will perish. The App Store is no different and I’m constantly dumb-founded as to why some people expect it to be so.

I’ve been using it for the past couple of months, for visualizations.

Here, go on and read the documentation. It’s rather well-written.

The short of it: You can access the API using Javascript. But the fun doesn’t begin until you’ve begun with KML.

More coming up. I’ve been working on this quite a bit.

To maximize sales, Web merchants need to create an Internet footprint that goes beyond the home page and extends to all parts of the Web where their customers congregate.

The best way to get there, said experts at the Web 2.0 Expo in New York, is through application programming interfaces, or APIs.

“Hoarding treasure is not valuable,” said Oren Michels, CEO of Mashery, a startup that helps companies extract the most value from their APIs and build scalable infrastructure around them.

APIs provide hooks so third-parties can leverage tools and content from partners—typically large e-commerce or media sites like Netflix (NSDQ: NFLX), Best Buy (NYSE: BBY), or The New York Times. Billboard.com, for instance, publishes an API that allows Facebook users to compile their own lists of top tunes from the music publisher’s massive database of Top 100 lists.

“When you open your services, you create a new means of distribution,” said Michels.

Still, using APIs to build revenue or brand awareness carries some risks. Content may be misused, improperly distributed to others, or republished in violation of terms of licensing or copyright agreements. Companies that use APIs therefore need to aggressively employ best practices and other, industry standard security measures to minimize the downside.

“APIs need strong governance models,” said Drew Bartkiewicz, VP for technology and new media at insurer The Hartford, “in case something goes viral.”

One way to minimize exposure is to create “sandboxes”—APIs that give users access to trial data but not real business content. That lets the provider ensure that the intended use for the information is legitimate before opening the door to actual data.

Still, said Michels, “you can be too cautious to the point where you’re not giving your partner anything of value.”

Source:

http://www.informationweek.com/news/software/hosted/showArticle.jhtml?articleID=221800435&cid=RSSfeed_TechWeb

Custom Web Design Chicago

Online subscriptions handling, recurring billing, up/downgrades, receipts, from end-to-end: Recurly; http://j.mp/2ecuyQ

So, a few weeks ago, I saw a new site launched: factual. The site’s goal seems to be to become sort of a wikipedia for data. At first, I thought to myself, “hey, isn’t that what wikipedia is?” But when I looked at the site, I understood a little better. Users can create tables that can be seen by others (or not) and updated by others (or not). The result is a type of open, community-editable database. This works better than text for a lot of things, because it is queryable and can be used to drive 3rd-part applications, but the data is still community-editable. There are provisions for correcting inaccurate data as well, so that the data converges to the most accurate possible.

At the moment, I’m not sure just how much data they’re hosting, but I like the idea. I was also quite pleased to see they are providing a developer API, which allows access to the publicly readable tables, and allows creation of new tables as well. That API is what has brought me here. I’ve decided to learn the Android APIs while implementing the Factual API. The result will be called Factoid, and I’ll be sharing my experiences with both APIs here, for whoever wants to read them. Note that I am not associated with either the Factual or Android projects, I just like them both and enjoy learning new things.

I do have a day job, so I’ll only be working on this in my spare time. I have started coding the project, however, and already have a few things I want to write about. We’ll see how this goes.

Bing integrates Wolfram Alpha, becomes the first customer of the new Wolfram Alpha API; http://j.mp/m4Ol5

Position: Programmer Analyst

Location: Piscataway, NJ

Engagement Model: Contract to Hire

This position is for a Sharepoint developer required to design, develop, implement and maintain Sharepoint sites and related applications & integrations.

• Senior developer for Sharepoint
• Design and develop Sharepoint integrated applications
• Maintain and support Sharepoint sites

Technical Skills and Experience Requirements:
* 3+ years MOSS experience
* Architecture Skills
* Business Analysis Skills
* Project Management Skills
* Familiar and participate in the SDLC
* SQL Server development (Stored Procedures), knowledge of database design and security
* Familiar with SharePoint administration, know how to create sites, create lists, create views, SharePoint security model best practices, along with implementing SharePoint security
* Concept of easy maintenance, not just build it, but build it with maintenance in mind

* Expert knowledge with
• built-in and out of the box capabilities of MOSS, built-in web parts
• know how to use content types and Features
• concepts of web applications and site collections
• web development/customization in javascript, HTML/DHTML, CSS, and ASP.NET, XML, XSD, XSL
• customization of WSS 3.0 and MOSS 2007 site templates and development of new templates
• creation of custom web parts using C#, Visual Studio
• SharePoint Web Portal development and design
• InfoPath 2007 Forms Services, Form design and deployment
• Business Data Catalog implementation and usage
• C#, .Net development, Custom web services
• SharePoint APIs
• CAML
• Designer Workflows

Please email your resume to uscareers at marlabs.com

Scott Thompson, president, PayPal

PayPal is opening up substantial parts of its global transactional engine, extending the open platform dubbed “PayPal X,” company executives announced this morning at PayPal’s X Innovate 2009 developer conference in San Francisco. PayPal developers and users now have access to a slew of new APIs, ranging from an extended version of the Adaptive Payments API that PayPal made available in July, to an Adaptive Accounts API designed to make it easier for people to sign up for accounts. The APIs, technical documentation, sample applications and more are available at PayPal’s X.com web site.

PayPal’s move to open its platform has been under way for some time, and it represents an important shift in the company’s strategy. It may usher in new breeds of payment-centric applications, including ones focused on microtransactions and mobile payments. In-application payments, which Apple (s aapl) is now allowing in iPhone apps, are also a focus for the PayPal X platform.

“We’re introducing new APIs and new pricing,” said Osama Bedier, VP of Platform technology at PayPal. Specifically, PayPal will charge 50 cents as a flat fee for transactions, in an effort to encourage more micropayments and applications that facilitate them. Many new APIs are available, and the snapshot of a  slide below shows only some of them. (All are available at X.com.)

The Adaptive Payments API has capabilities for currency conversion, enhancements such as faster pre-approval,  and can send payments between many types of mobile devices, Bedier said. Mobile devices, in fact, were much discussed at the conference. PayPal President Scott Thompson said that “cash is obsolete,” and added:

Think about the possibilities for things like mobile money through an open platform, and how the mobile wallet will live in the cloud. The network is the platform on which the potential for digital money will be fully realized.

Thompson said that there are over 78 million active PayPal accounts, and Bedier added that PayPal transactions total more than $70 billion per year, but eBay (s ebay) CEO John Donahoe said he expects PayPal to get much bigger, and, in fact, become much bigger than eBay is. “We believe that the Internet, and e-commerce, and online payments are still in their early days. E-commerce is only 15 years old, and online payments are only 10 years old,” Donahoe said.

He also said that “while eBay and PayPal and Skype have all enjoyed enormous success, quite frankly, beyond our business model, we’ve never been known as particularly innovative. So I’m putting technology people in charge.” He singled out Thompson’s appointment as president of PayPal, and noted that he recruited Marc Andreessen to eBay’s board for the same reason.

PayPal’s Open X platform looks like a good move toward openness for the company as in-app payments, mobile applications that emphasize payments, microtransactions and other trends change the company’s business.  More openness may also be a good answer to increasing competition from Google Checkout, Checkout from Amazon, and transactions on Facebook.

It remains to be seen how open PayPal will really be with Open X, though. There is a big difference between opening up APIs and open sourcing critical code components. Time will tell if PayPal’s partially open bet pays off.

It will be very hard for you to believe, but I actually had a good day at work yesterday.

We had guests yesterday who gave us a very fine presentation. My co-workers were very well spoken and represented themselves well. Everything went smoothly, I think.

I really didn’t get any work done yesterday and some people I know would argue that lack of work done can make for a really great day at work. This is one of the few days that I didn’t regret not getting all of my work done.

My friend @nicchick asked a question last night, at a meeting of Twitter users here in Marbella, about API limits on twitter. A few people had a go at explaining this, but she admitted in a tweet this morning that it was still a mystery.

Her problem is that when she’s on Twitter using Mixero, her preferred Twitter client, she keeps getting messages like “API limit exceeded 10 mins to refresh”. So she wanted to know why this was happening and how she could get around it for uninterrupted twittering.

So I had another go at explaining the concept this morning in a 140 character Q&A session, but I’d like to go into more depth here, it seems to be a common cause for confusion.

First, a little background: Twitter is a young company, only 3 years old. Although they’ve had a lot of success in a very short time, it’s founders are wary of growing too fast too soon. Evan Williams and Biz Stone have decided to hire new staff gradually to preserve the unique company culture that makes Twitter a great place to work.

This also puts limits on the number of servers and infrastructure they can manage. Twitter is listening to thousands of tweets every second, storing them in a searchable database and serving them up, hundreds at a time to avid followers all over the world. The application and database servers that handle this data all need to be installed, monitored and maintained by people. So as twitter grows slowly, so does the infrastructure (I’m over simplifying a bit here for brevity).

O'Reilly Media

But one of the cleverest things Twitter has done is give 3rd party programmers direct access to the database through a technology called API (Application Programming Interface). The twitter API makes the plethora of twitter clients and twitter utility sites possible. The downside is that as these apps and services become more popular the load on twitter’s infrastructure increases. So to prevent the servers becoming a victim of their own success an API limit was imposed.

The API limit is currently 150 calls per hour for each user or IP address, this means that if you open TweetDeck and hit refresh another 149 times in 40 mins you’ll be locked out by twitter for the remaining 20 mins until you get a fresh allotment.

In theory posting a new tweet dosen’t get charged from your limit, but most Apps like to show you the tweet you just posted. In order to be user friendly they send an API request for all new tweets in your timeline (including your own), right after your tweet has been sent, and this reduces your hourly allotment by 1 call.

If you want to reduce the number of API call you use, try changing the preferences in your client to send fewer requests, or reduce the number of search columns you use at once.

HootSuite Screenshot

You could also try switching to HootSuite (I’m a user of HootSuite) which is a web based twitter client that has been white-listed by twitter. HootSuite gets an hourly allowance of 20,000 API requests!Obviously this allowance is shared among the many users of the site.

I’ve never had a problem with API limits on HootSuite, so I assume it’s able to intelligently throttle it’s requests. If it find it’s getting close to it’s 20,000 limit, the web app just refreshes your columns a little less often or puts users to sleep a little sooner to make it’s allotment last till the top of the hour. And if it’s not, it should be!

Polyamorie (von griech. polys, “viel” und lat. amor, “Liebe”) ist ein Oberbegriff für die Praxis, Liebesbeziehungen zu mehr als einem Menschen zur gleichen Zeit zu haben, mit vollem Wissen und Einverständnis aller beteiligten Partner. Die angestrebten Beziehungen sind langfristig und vertrauensvoll angelegt und schließen normalerweise (aber nicht unbedingt) Verliebtheit und Teilen von Zärtlichkeit und Sexualität mit ein. Der Begriff der Liebe wird also weiter gefasst als bei der romantischen Zweierbeziehung.

Polyamorie ist ein Wort, das etwa 1990 “erfunden” und seit 1992 in elektronischen Foren popularisiert wurde. Es handelt sich um einen Sammelbegriff, der alle einvernehmlichen und auf voller Informiertheit beruhenden langfristigen intimen Beziehungen mehrerer Personen beschreibt. Die zugehörige Subkultur hat Wurzeln in der “Free Love” Bewegung seit Mitte des 19. Jahrhunderts, grenzt sich allerdings von, in den 1960er Jahren entwickelten, auf Sexualität eingeschränkten Fassungen des Begriffs “Freie Liebe” ab.

Wikipedia widmet dem Thema einen umfassenden Artikel.

Infos zum Thema unter: http://www.polyamorie.de/

Redaktionen finden umfassendes Bildmaterial …

… auch zu den Themen der Sexualität in unserem gut sortierten Bildarchiv bei Mecom-Multimedia (recherchierbar auch über APIS bzw. i-picturemaxx). Wir produzieren auch im Auftrag und führen für Sie Recherchen und/oder Interviews durch. Auch in filmischer Form für Online oder TV.

© Franz Roth

Tiermumien? Als ich das Cover von der aktuellen National Geographic sah, wurde ich schon sehr neugierig. Die Geschichte ist auch spannend: Die alten Ägypter liessen Ihre Haustiere ebenfalls mumifzieren und in die Gräber legen. Aber auch Tiere, welche man als Stellvertreter der Götter hielt. Neben der sehr beliebten Katze fand man deshalb Krokodile,  Gazellen und auch andere Tiere. Das wichtigste von allen, der Apis-Stier, wurde bisher in keinem Grab gefunden. Aber die Balsamierungsstätten kann man besichtigen.

Bestellen auf www.buy.ch

Interessant ist auch, dass diese Tiermumien lange Zeit unbeachtet blieben und zu tausenden aus Ägypten nach England als Dünger verschifft wurden. Erst im letzten Jahrhundert hat man angefangen die Bedeutung dieser Tiere genauer zu erforschen. Heute findet man zahlreiche dieser Mumien im berühmten Museum in Kairo.

If you live in Europe there are many opportunities for visiting the rest of the continent without spending much. There are more than 60 low cost airlines (e.g., Ryanair, EasyJet, …) and today they fly almost everywhere. Here are a couple of examples: two-ways ticket Pisa-Paris is about 50 euros in December, London-Barcelona about 80 euros.

The smart traveler probably figured out by now that can also use low-cost airlines to connect with the hubs of big airlines and save on all its travels. For example, a trip to New York City costs thousands of euros on average, but hopping through London with a low-cost flight can shave more than half of the cost. I do it regularly from Pisa to Denver, flying to London with Ryanair and then using British Airways.

Unfortunately, finding those deals is very complicated, if not impossible, for the average customer. Those flights and airlines are not listed in the normal ticketing system and thus Expedia, Orbitz or your local travel agent will not help you to find them.

You have to visit the site of your local airport, finding out which low-cost airlines fly there and where they go. Then manually go and check each site for dates and prices. That $50 weekend in Amsterdam exists, it’s just hard to find.

The solution? Open APIs and entrepreneurial spirits.

Low cost airlines should provide APIs to:

• Given an airport, list reachable destinations and flight times
• Given a route and a date, show ticket prices for a 2 week range

Then just sit and wait a couple of weeks. Smart kids around the globe will create mashups between those APIs, Google Maps, Wheater.com, OpenTable, TripAdvisor and who knows what else.

Those application will suggest you cheap weekends getaways from your local airport (or one nearby) using low-cost flights and checking forecast and travelers opinions in a simple calendar view, will show you ways to get on-time to that amazing Munich-Chicago flight deal on Wednesday morning without having to sell your car to buy the ticket from Lufthansa, or combine multiple low-cost carriers to fly you from Barcelona to Frankfurt for the cost of a DVD.

Airlines will be happy, because to buy the tickets customers will have to follow a link to their official site (landing directly to the checkout page), where they will able to rule their reign and continue to propose their “car/hotel bundle packages”.

Customers will be happy, because they will be able to finally afford to travel around and will get to know all the options available.

Entrepreneurs will be happy, because will have a new fertile ground to build the next travel app (last one was Kayak). And even if the airlines will not offer affiliate programs (e.g., give 3% of the ticket price to the author of the site) to make their API more interesting, I am sure that smart entrepreneurs will find other ways to generate revenues for their sites.

Yahoo Meme released an API for third party developers built on top of the YQL; http://j.mp/WONAM

I actually wrote a post yesterday, but somehow I forgot to publish the thing. So, that’s posted prior to this one.

To explain how I feel about work right now.

I was notified on Friday that I get to spend another 12 months, give or take, at my assigned task. I think we can all agree that this makes me happy.

Unfortunately, because there’s someone out there that likes to stir the pot, I’m losing my two best people. And getting two unknowns in the process.

It really means something when one of the air thieves takes a look at one of the replacement names and starts freaking out. I had three knuckleheads weeping and wailing in the office about how screwed we all are because replacement #1 is apparently a real piece of work.

So, stress and trepidation are winning out over happiness right now, but I guess that’s why they pay me the big bucks.