Thursday, January 19, 2012
Yesterday evening, in the midst of the blackouts instituted by Google, Wikipedia and several other large organizations, I noticed one of my interfaces stopped working. I am sure the interface was working earlier in the day, because the page it is on-- is one I check constantly during the day.
The broken feed was on the WiredPages-- Arts & Entertainment page. This morning when I noticed it was still in disrepair-- I did not research the code-- instead planned to put up a temporary xml file that my program would read.
The data for the feed is updated weekly, so simply updating the xml file every Monday would have been a relatively easy task-- until I could find a replacement data source.
That is when I loaded my IDE and looked at the code-- in anticipation of using the new temporary xml file. Turns out-- it was a little more involved than my data source not updating a feed. I corrected the problem without using the temporary xml file. The fix-- would not be an easy repair for someone without my experience.
When my news service was very young-- 2002 or so- XML and RSS were not widely offered. Today they are and what I know think of as the more conventional mode of data delivery between sites. Back then, to populate my site with news headlines I often used unconventional methods to obtain the headlines. Hard? Not for someone with my c background.
Today, of course pretty xml files exist-- that I use often. The data source that broke was not a pretty xml file.
That said-- when I build interfaces for clients-- I do not use unconventional methods to get the data, however often API or web service providers make things hard for developers. A web service or API provider is unlikely to change how the data is offered over the course of a year or two- so not a problem for most programmers or their clients. Unconventional [but legal] retrieval of data-- is less guaranteed to work after a period of time- and the reason most programmers do not offer these services to clients.
All of this to say- if QiSoftware builds your interface-- it will work within 24 hours after a problem arises-- for the lifetime of the application.
I get to issues with my news service when I feel like it -- so if you too noticed the break when I did yesterday-- I made a mistake thinking my data source was participating in the black out [partial] and I did not even investigate the problem until this morning. Your house is not my house. I would have looked at a client's problem long before I did my own.
Friday, January 13, 2012
Recently, I have been inundated with repairs and updates to WiredPages and other areas of my sites.
Whenever I experience times like this-- I often wonder what other web site owners requiring the same type of emergency "repairs", do. I can stop whatever I am doing, and make the repairs. I am the programmer and designer behind all of the work for my sites.
In that the repairs are mostly to interfaces I maintain on WiredPages-- how is it that I focus business promotion on similar tools for your sites?
Recently, I read a job proposal wherein the job poster wanted a guarantee that anyone providing him with a new PHP script for his project-- also provide a guarantee it would not break within months.
I thought to myself-- well one thing the poster might want to do-- is consider a non-open script language [PHP is an open script language] for his project. I did not bid on his project.
Did you know-- that when web hosts find a problem with a script that requires too much in the way of system resources-- they can disable it very easily, at their discretion? And, if you check the fine print of your hosting agreement-- in most cases-- it is perfectly legal. The script is open source and sitting on their servers.
Java Servlet interfaces-- in most cases, prevents this type of tampering by web hosts. Also-- because the Java Servlet is more efficient than the PHP script, anyway-- the web host is less likely to consider it the resource hog or problem.
So what about maintenance issues for QiSoftware developed interfaces? QiSoftware guarantees the repair of custom interfaces within 24 hours of notice-- for the life of the QiSoftware developed custom interface.
Recently, I had several issues that I documented on my personal blog-- and also provided a cost estimate to have the work done on the outside.
I do not take on all clients. I work hard at keeping clients I do take- happy. I also fix-- what breaks. And, I put it in writing.
Friday, January 06, 2012
Spoke with a representative from the consumer guide whose interface I installed recently on WiredPages- and subsequently removed within days-- because hosting-q.com access was blocked. Reminder, my interface could access their API from qisoftware.com, however I opted out of this solution.
Bit of an odd conversation. He called on the premise I had posted a branding question in their forums earlier-- and he wanted to get in touch on that basis- according to his email. He called around 3:15 p.m. on Wednesday. Quite frankly, since he set the call time and it was for 3:00 p.m., I thought he decided to cancel. When he did call-- I was again surprised that he seemed to want nothing.
He did indicate he did not want my API interface to run in "that location"-- and I said okay. I started with the branding question-- but he wanted to talk about the interface.
Business wise-- I am direct. I deal in logic on a daily basis and do not deal in abstracts-- unless to try and understand someone else's. If I did deal in abstracts, as related to business- I would never get anything done. Read my blog posts over the last 6 months. I have gotten a lot done- under less than optimal conditions.
You are a real business person- I do not need to explain this to you. I had already explained in at least two personal blog entries-- I would not be moving interfaces from hosting-q.com to qisoftware.com.
Posting this reminder on the more official business blog-- to see if real business people want to stop wasting my time..
In a movie I saw with William Hurt, who played Hank Paulson-- "Too Big to Fail"-- Hurt says-- "they grinned f'd us". Was this an attempt on his part to grin ...? Why? I knew what I was not going to be doing-- so he wasted his dime-- and the email he sent to set the appointment.. I expect this from government workers. Not real business people.
I am in business. I had already made my plans clear. I repeat, I am in business. Real business people should believe my no- and not waste my time. U.S. government [locals silly enough to interfere too]-- do not have your people call as related to my business. I am owed calls from the FBI and DOJ. I do not expect calls from government personnel unless from those I have indicated.. Tired of telling you this. And believe me - if I am posting about this-- in this blog, you should pay attention.
I got up from the call with a big, huh? Why on earth did he call. I did not feel grin f'd. I felt I was dealing with someone not as clever as he thought he was.