Spiga
Showing posts with label Web. Show all posts
Showing posts with label Web. Show all posts

Pizza - the Top Trend Mobile Search

V-Enable, a voice-enabled mobile 411 system, conducted a study by taking a random sampling of 20,000 searches in major metropolitan areas from customers of several V-Enable partner carriers including Alltel and MetroPCS. The findings clearly represent interesting trends caused by the recession. For one thing, people are eating more pizza! The results for the top restaurant searches for the period between October 2007 and June 2008 are:

1. Pizza Hut
2. McDonald’s
3. Domino’s Pizza
4. Starbucks
5. Papa John’s Pizza
6. Little Caesars Pizza
7. Taco Bell
8. Burger King
9. Wendy’s
10. Denny’s


Sit-down restaurants like Olive Garden, Applebee’s and Red Lobster, have dropped off the list, while recession-proof comfort food like Pizza Hut and Domino’s shoot to the top of the list. 380% more searches for Pizza Hut have been conducted during the period, and searches for Domino’s Pizza have increased 980%. High gas prices are keeping people at home ordering in, and they are opting for cheaper alternatives. Financial analysts have explored this area extensively, and have deemed several of these restaurant chains "recession-proof stocks."


There are several other search-related economic indicators from V-Enable. U-Haul, a company that was never on any top 50 list, jumped to #23 in general search, possibly because of a rise in foreclosures. Macy’s dropped from #17 to #49 in retail, a direct correlation to the fact that people just don’t have the discretionary income that they used to. Motel 6 has never showed up on a top 50 list, but they are now #37 in general search, quite possibly because travelers can’t afford the costly alternatives. Mobile search happens in real-time and is unaffected by SEO, making these statistics arguably more reflective of consumer sentiment than web search.


V-Enable is a mobile information system, where users can speak the name of a restaurant or residential listing and receive location and contact information. The company also has live operators working behind the scenes so that users can call and get human assistance, if necessary. V-Enable sent us similar retail statistics in December. The company is backed by $10.1 million over 3 rounds from Siemens Mobile Acceleration Corporation, Sorrento Ventures, SoftBank Capital and Palisades Ventures.


credit : techcrunch

Preventing Phishing attacks

Phishing Attack


Phishing is a type of attack wherein the attacker impersonates a valid site and steals sensitive information entered by the customer on the fake site.

The attacker sends the victim a forged e-mail having the link of a fake page. The fake page looks exactly like a valid page of the original site. These e-mails have upsetting or exciting (but false) statements to get the customer to react immediately. When the customer clicks the link, he is asked to provide his credentials to login and update his personal information. This reveals important information to the attackers.

Steps to prevent these Attack


The best way to prevent phishing attacks is by creating customer awareness. Some important points that need to be communicated to the customers includes:

1.  Organizations should constantly remind their customers that they will never request for sensitive information via e-mails. Moreover all email communications should address the customer by first and last name.

2.  Customers need to be educated not to click on URL of critical website (e.g. Internet banking website) that comes via email but visit these websites by directly typing the address in the browser.

3. Customers should be educated on identifying secure websites, like https in URL or ‘Lock’ icon, before submitting username, password, credit card number and other sensitive information.

4. Customers should be educated about choosing strong passwords and the importance of changing them regularly.  How to choose a Strong Password

5. Customers should be educated to be suspicious of any e-mail with urgent request for personal information.

6. Customers should be provided with easy methods to report phishing incidents.

if you have any other steps to prevent phishing attacks, please share with us by comments.

Click the wrong link and wind up in jail

In the 10 Things blog, Deb Shinder recently pointed out 10 ways you might be breaking the law with your computer and not even know it. There’s yet another way that wasn’t mentioned in that article. Specifically it has to do with recent arrests made by the FBI in suspected child pornography cases.

As has been reported in News.com and elsewhere, the FBI has been recently employing fake Web sites to lure people into child pornography. A suspect doesn’t have to have any child pornography on his computer either. Merely clicking the link is enough to trigger an investigation, search warrants, and the resultant perp walk, whether or not there was any intent to indeed consume child pornography as part of the clicking.

Improbable cause


But what if the user didn’t know the images were on the computer? Or what if the user didn’t know what the Web site was before it was clicked?

Sorry. That doesn’t count. The link got clicked. The images are on the computer. Go to jail. Go directly to jail. Don’t pass Go. Don’t collect $200.

Certainly such a thing wouldn’t happen, right? The only way someone could go to a kiddie porn site was to find the link and intentionally click it. As an IT leader you do, or should, know better.

There are many, many different ways users can be tricked into clicking things or winding up on sites they shouldn’t have. First, there’s the obvious things that can happen when viruses or other malware redirect browsers to go places they’re not supposed to. Someone could program a simple redirect in a Web site, maybe through something as simple as a clear gif, forwarding a browser to the target Web site. Even something as simple as creating a link in TinyURL that points to the site.

TinyURL is especially dangerous, because there’s no way to know exactly what the destination address is before the user goes there. It could be an easy tool for one user to use against another as a cruel joke or some form of retaliation.

Read More

Tips for Debugging Ajax Applications - Part2

part1

1. Use Javascript alerts to indicate the values of variables.
There are three families of values you'll need to confirm:

  • Values received by a function:
    alert(value);
    Use this for any Javascript function, like the one triggered by the HTML event or the one called when the PHP script returns its value.

  • Values returned by the PHP script:
    alert(ajax.responseText);
    Since responseText stores the data you'll deal with in the Javascript, confirming its value is a great debugging technique.

  • Values to be assigned to HTML elements:
    alert(message);
    You could also have problems in writing new HTML to the web page.In such cases, you'll need to confirm if the problem is in the message being written (tested using such a alert) or in the writing process itself(i.e., assigning a value to innerHTML).

2. Make sure you reload your Web browser after making changes. Failure to do so in common, and very frustrating, mistake.

3. Test with multiple browsers. With Javascript and HTML, different browsers can behave differently, so see how your applications behave in multiple browsers.

4. Watch the method --GET or POST-- being used. Some browsers (I'm looking at you Internet Explorer) cache GET page requests, so it might look as if the changes you made didn't take effort.

5. Use a Javascript console. Good browsers, like Firefox and Safari, can show Javascript errors in a separate window.

6. Use a Javascript debugger. Firefox users benefit greatly from the Venkman debugger(www.mozilla.org/projects/venkman). Internet Explorer users have the Microsoft Script Debugger.

Programming Tips

Here are some tips and things I've found to be true after 5 years of software experience.

Follow Einstein's maxim; keep things as simple as possible but not too simple.

If you are having difficulty coding your design, stop - you are probably going about it the wrong way, rethink the design.

Get help if you need it, but try wherever possible to work things by yourself, you will learn faster; it's not good having someone write code that you don't understand!.

Bear in mind that most importantly, the programmer must have a clear idea of what is required before coding commences. In a simple gauge this may mean just keeping what's needed in mind, in complex projects you must have to write your intentions or even make a flow chart of how things will work. Believe me, you will save much time and frustration by working this way, not to mention the umpteen versions of scrapped code!.

Software like painting, is a creative endeavour; there are many things to achieve the same end result; If you asked two artists to paint a horse the results would look like a horse but would not look as same each other, software is like that and the best software will achieve the result with the minimum possible code.

As you become proficient at coding you will find yourself getting good results quickly with elegant code, looking back at your early efforts will make you laugh - laugh heartly, it's a good sign.

Do you have anything to share? Please post them in the comments below.

Know When You Shouldn't Use Ajax

Ajax is, without a doubt, preety cool, but what's cool isn't always what's best (despite what you thought in high school). As with any technology, employ Ajax because you should (when it adds useful features without adding more problems and excluding users), not because you can or know how.

Since Ajax relies upon Javascript, one potential problem is that not all users enable Javascript and it can run differently on different browsers. A well-implemented Ajax example can work seamlessly on any browser, but you really need to be thorough. You can also create a non-Ajax version of a system for those with Javascript disabled: not difficult, but again, something you do need to think about.

Another problem is that Ajax renders the browser's history feature unusable. For that matter, you can't bookmark Ajax pages the way you can search results (the page itself can be bookmarked, but not after some interaction). So by adding functionality, your Ajax application will remove common features.

And Ajax request still require a server connection and the data transfer, so they don't save any resources, just reallocate them.

Finally, I'll point out that there's an argument to be made that IFrames offer similar functionality to Ajax but without some of its downsides.

Tips for Debugging Ajax Applications - Part1

Debugging your Ajax applications can be quite challenging because:
  • There are so many technologies involved(PHP, MySQL, Javascript, DOM, and HTML).
  • You may be less familiar with Javascript and DOM.
  • Much of what happens goes on behind the scenes.
  • Because of the Javascript, you really need to test your applications on multiple browsers and platforms to ensure universal reliability.
In my experience developing Ajax applications from scratch, I've picked up quite a few useful debugging techniques, outlined in the following steps.

1. Run your applications through a URL!

For the PHP to work, it must be accessed through http://. This means that you must load your HTML page through http://.


2. Test your PHP scripts separately.

Be in the habit of doing this automatically, not just when things go awry.


3. Test your database queries separately.

Print out the exact query(ies) and use another interface, like the mysql client or phpMyAdmin, to confirm the results.


4. Validate, if appropriate, the data returned by the PHP script.

If the JavaScript function handling the returned data expects to receive XML or JSON, then the returned text must be in strict XML or JSON format.


5. Use Javascript alerts to indicate what's going on.

Since so much is going on behind the scenes, it's often necessary to shed some light on the process.Add code like alert('in the check_user() function'); to your Javascript code.


Additional tips for debugging ajax applications will be covered in part 2.

10 Tips for Securing your PC

Here are the Ten Tips for Securing your PC.
  • Create strong passwords
  • Use good antivirus software
  • Windows users shall regularly update critical updates
  • Download online forms after verifying URL https:// or forms with lock icons
  • Use secure shell (ssh or sftp) for file transfers
  • Not open unnecessary emails
  • Regularly back up important files
  • Set a password protected screen saver to activate after 10-15 minutes
  • Shutdown thine computer at night
  • Schedule monthly scanning of hard disk
As always I look forward to your feedback. If you have made this transition yourself, please add your tips for others to learn from.

10 Tips for Moving From Programmer to Entrepreneur


1) Code is 5% of your business
One of the biggest issues I see is developers getting caught up in the code. Spending countless hours making a function perfect or building features which show off the latest technology. Now you have to write code to be in the software business. It has to be high quality code that isn’t filled with bugs or is insecure. However, the best code in the world is meaningless if nobody knows about your product. Code is meaningless if the IRS comes and throws you in jail because you didn’t do your taxes. Code is meaningless if you get sued because you didn’t bother having a software license created by a lawyer.

I see way too many entrepreneurs in the forums and blogs talking about code issues when they should be discussing and learning about the business aspects. Of course that’s harder then talking about code, but nobody ever said this would be easy!

2) Design is everything, relative to the competition
Your product has to be nicely designed. Standard programmer square boxes with gray backgrounds don’t cut it! Remember though that your design only needs to be nicer than the competition. So if you’re building a back office IT system there’s no need to bring your design all the way up to the level of a 37 Signals type app. Of course it’s great if you do, but the goal here is simply to make it clear for your customers that you have the nicer design when they compare your product to the competition. People DO judge books by their covers.

3) Get used to thinking long term
There’s nothing a programmer likes better than turning code around fast. Getting bugs in and squashing them. The problem is that most non-programming related tasks in a small ISV don’t happen quickly. You really need to think long term. Things like getting your marketing and product positioning in place can take months to years. There’s no instant gratification like you get from writing code, so you must always force yourself to think long term. Where do you want the product, marketing, and sales to be 6 months from now?

4) Admit that you don’t understand the end user and rectify that
There’s a good chance that the software you are writing is in a domain you are not an expert in. That’s where the opportunities are and that’s great, but you have to realize that you need to do more than just research the market. You need to understand the actual customers. Talk with them. I know you don’t want to but it’s an absolute must. Without talking to the actual end users you’ll never know what features you’re wasting your time on and which ones you don’t have that are critical.

A big mistake people make here is implementing the feature set of the competition to get started. That’s a bad move. It’s like when you copy your friends homework. You both end up with the same mistakes. By talking to the customers you can avoid the mistakes your competition has already made.

5) Love your customers
Many software developers come from a back office IT background. In most of the IT shops I worked in there was generally disdain for the customer (internal customers). It’s not surprising since IT is often asked to do far too much with far too little.

It’s time to put all that aside though. I see a lot of ISV’s who seem to carry this over and there’s no place in commercial software for it. The only way to be successful is to love your customers. That means meeting their needs as much as possible and going to great lengths to do so. When you can’t you need to explain why. When they choose a competitors product be respectful and remind them the visit you again if that product doesn’t end up meeting their needs.  I’ve found that I’ve switched lost sales back to me simply by being nice to the customer on their way out the door.

6) Remember to design for ease of use. Even advanced users like easy.
Your user interface is no place for fancy technology tricks. Keep is simple. Advanced users love simple just as much as newbie’s. The most important reason to keep is simple is for your trial users. A trial user is only going to give you a few minutes of their time. If you waste it by making them figure out a complex interface you can bet they’ll be off looking for another solution.

7) Remember to bounce your ideas off people who aren’t working on the project
Make sure to always take time to show off your latest builds to someone who’s not very involved with the project. Fresh eyes will often find big holes in your user interface. Even if the person doesn’t know much about your domain, you’ll be surprised at how many issues they’ll point out that you’ve never seen before!

8) Don’t be afraid to pull things out
There’s nothing I hate more as a programmer than pulling perfectly good code out of an application. Alas, you’re going to have to do it. Through the process of developing you’re going to discover features that should never have been. Ideally you’ll find this out before actually shipping. When you find these features you need to pull them before they cause any trouble.

For example, when I was half way through developing HelpSpot I discovered that one of my features just wasn’t working. I had built this tool for importing customer information into HelpSpot. This was a bad idea because it basically turned HelpSpot into a half baked CRM. It meant my customers would have to keep HelpSpot in sync with their real CRM and generally made the UI more complicated. So I scrapped a few weeks of work and pulled it out.

It turns out to be one of the best decisions I made. Rather than the syncing I came up with the Live Lookup system which allows customers to run queries against their existing CRM from within HelpSpot. It’s turned out to be a unique feature which is used by the majority of HelpSpot installations very successfully.

9) Patience is a virtue
There’s invariably a lack of time to get all the things done you need to. What would normally take a day takes weeks. Try to learn patience. I’ve found that I have to actively work at this or I get frustrated that I’m not making enough progress. Avoid setting up dates and expectations with your customers when possible. Don’t promise something in a month if it might take 3. I’m still working on that one myself

10) Treat it like you are learning to program all over
Remember when you first learned to program and you read every book. You bought 8 different books on that first language all of which basically said the same things but you read them all anyway because you couldn’t get enough. That’s how you have to treat the transition from programmer to entrepreneur. Read everything you can get your hands on about your target market, running a small business, marketing, general management, time management. Ideally you should read it before you even start coding. The mistakes you’ll be able to avoid by doing so are well worth the time commitment.

As always I look forward to your feedback. If you have made this transition yourself, please add your tips for others to learn from.

Article Source - Click Here

U.S. Internet Will Shrink To 2 Strong Players

An Internet analyst for a major Wall Street firm argues in a new report that Google and Amazon.com will be long-term winners, while Yahoo and IAC InterActiveCorp fall by the wayside and eBay becomes a merger target.

SAN FRANCISCO, June 2 - An Internet analyst for a major Wall Street firm argues in a new report that Google and Amazon (NSDQ: AMZN).com will be long-term winners, while Yahoo (NSDQ: YHOO) and IAC InterActiveCorp fall by the wayside and eBay (NSDQ: EBAY) becomes a merger target.

Sanford C. Bernstein analyst Jeffrey Lindsay argues in a 310-page report entitled "U.S. Internet: The End of the beginning" to be published on Tuesday that Google (NSDQ: GOOG) and Amazon are best placed to withstand the current economic downturn.

"We expect two players to continue to perform strongly, Google and Amazon," Lindsay writes. "Both Google and Amazon.com are still racking up annual growth rates in the 30-40 percent
range, with only a relatively modest slowdown in sight."

Lindsay reiterates his previous positions that Yahoo eventually will be sold to Microsoft and that Barry Diller's IAC e-commerce conglomerate will go ahead in August with its five-way split-up, as planned.

"Arguably the weakest players have strayed furthest from their original competences and have been operating largely as conglomerates," the Bernstein analyst says of Yahoo and IAC.

In the short-run, however, Lindsay believes Yahoo will see gains if it reaches a deal to turn over some part of its searchadvertising sales to Google to run or if Microsoft resumes acquisition negotiations.

He argues that eBay "could potentially attract a Microsoft-like suitor in the future," especially if growth in its core auctions business fails to resume and because eBay could spin off its PayPal or Skype units to make a deal work.

Even the strongest companies have weakness, Lindsay argues. Google has yet to articulate a compelling strategy to achieve the same level of strength on the emerging mobile Internet that it has on the computer-based Web.

Amazon and eBay are likely to be forced eventually to pay state sales taxes. Ironically, he notes, this may work to their advantage as large companies, because they have more resources than smaller e-commerce players to collect such taxes. (Reporting by Eric Auchard; Editing by Kim Coghill).

The Next-Gen Web: Browser Storage Support

lame_logo The next-gen web is starting to gather pace, as this week MySpace integrated Google Gears, Yahoo! announced their new BrowserPlus product and Google launched a browser-based edition of their 3D Earth product. Technologies and formats such as AIR, Silverlight, JavaFX, Gears, XUL, Web Applications 1.0 (DOM5, HTML5 etc.) allow developers to accelerate beyond AJAX and towards a new generation of web applications with better performance, more functionality and tighter desktop integration.

Developers and users are now presented with more web technology choice then ever before; “DLL hell” has been superseded by “plug-in hell”, as a variety of companies present their versions of what the next-gen web will look like. But on the web, such choice can come at a cost to both users and developers. More than a decade has passed since the first battle over web formats, back then it was Microsoft, Netscape, Apple, AOL and others laying different foundations in the form of browsers, scripting languages, web servers and more. The legacy of that battle is still being felt today, as Javascript developers rely on whole libraries to assist them in developing cross-browser code and CSS developers depend on a catalog of hacks so that their sites can look consistent across different browsers.

With the new rich web application technologies still in the development phase, there is an opportunity to not repeat the mistakes of the past and instead take a standards-based approach. Thankfully during the course of the previous decade companies such as Microsoft became more receptive to open standards, data portability and cross-platform support. Having broad support for open standards simplifies technology for both users and developers, but it is obvious that not all of the currently announced technologies, such as those listed above, will

Browser-based Local Storage

As web applications became more popular there was a general demand for an ability to run web-based applications offline. The first such solutions that could work without requiring a browser plugin or separate application were those that relied on the caching headers within HTTP to store objects within the browsers cache. Javascript libraries such as Dojo implemented support for offline web applications using the same principals, but applications were very limited in scope as there was no easy way to store structured data on the browser (Dojo now also abstracts a variety of other storage engines including Gears - tip: Dylan) .

In May of 2007, Google launched Google Gears, a browser plugin that allows web applications to synchronize data into a local data store and then allow web applications to function offline. At the launch of Gears, Google Reader was adapted to support it, and the emphasis of the pitch for Gears was about offline application access. What was less known is that Gears is a lot more than just offline access, as it provides three primary functions:

  • Caching of resources (HTML pages, images etc.)
  • Structured data storage in a database
  • Asynchronous background worker threads
The part of this we will focus on here is the local object and structured data storage. Gears provides these functions via a Javascript API, which can be accessed by any web application. The structured storage is provided by Sqlite, a popular lightweight RDBMS. With the local database, the developer can not only perform queries and inserts to record new data, but also more complex SQL like joining between tables etc. Although you can have multiple applications using Gears, each app runs in a sanboxed environment with a domain-based security model (similar to cookies and Ajax requests). Sqlite has been built into Firefox since version 2.0, but its API is only accessible from an add-on or a core Firefox component. The Gears plugin bridges that gap and makes it available within the client scripting environment.

Before Gears was launched, the Web Hypertext Application Technology Workgroup (WHATWG) had begun work on its Web Applications 1.0 draft spec, which included structured data storage as part of HTML5. The current draft spec from the working group includes definitions for a Database object for accessing and querying a local data store. The details of the implementation are left up to the vendor, but the API is detailed in the spec. Firefox will be implementing parts of the same storage API from the WHATW spec in version 3.0 of the browser, which is currently available as a preview release. The key components of the WHATWG spec are:
  • ApplicationCache - for storing objects in the local browser cache (and checking them)
  • navigator.onLine - check if the browser is online or not (and use cache plus local data store if required)
  • Storage interface and events - used for storing name and value pairs via the sessionStorage DOM attribute.
  • Database interface - used for connecting to the local database. Supports SQL (or a subset thereof, depending on the server used), versioning, error events via callback
  • Threading and Callbacks - so that multiple requests can be sent to the local data store asynchronously.
Implementing local storage, caching and offline access are relatively easy. The application can first check to see if these functions are supported, and then setup the local cache by synchronizing the users data in background processes. While a thread is running, either uploading or downloading, you can query it to check on its status to provide the user with feedback (eg. a progress bar). Once the data is local, by running database queries on the local machine developers are able to drastically improve performance. Currently many web applications use the browser as only a presentation layer, for eg. a spreadsheet application may do a round-trip back to the server to work out even elementary calculations such as =1+1. By utilizing the local data store and client-side code, the developer is able to offload processing and storage to the client and provide a much smoother, desktop-like experience at the same time.

Current And Future Support

The issue is that the majority of the WHATW specification was written after Gears was released, so the Database and LocalServer objects used in Gears are not compatible with WHATW - for now. The good news is that Google have come out and fully backed the storage portions of the WHATWG HTML5 spec, so developers with apps running on Firefox 3 with Gears installed will have a choice to use either the native implementation, or the Google implementation. Google go on to say that they will likely offer extra features as an incentive for developers to continue to target Gears over-and-above the HTML5 implementation (features such as desktop shortcuts, etc.).

Other alternatives for local data storage, such as Flash local storage, are completely incompatible with the WHATW specification. The developers at WebKit were very quick to announce that they have started implementing the storage portions of the HTML5 spec also. It is currently available in nightly builds, so in the near future we will see support in both Konquror and Safari. Opera have also announced similar plans and they are actually leading everybody when it comes to implementing HTML5 and Web Forms. Yahoo! BrowserPlus was only announced yesterday, and it is currently unclear wether their local storage support is compatible with the specification as laid out by the working group.

Local storage is a major new feature of the new web API, and developers will not only have consistent support across browsers but will also have the option of Google Gears (which is already available) as well as Yahoo! BrowserPlus (depending on how it works). There is just one browser maker missing in this discussion so far and that is Microsoft. Microsoft have released an early preview of IE8 and announced a raft of new features, a lot of which are based on open standards such as better CSS and Javascript support (with a more standardized object model). The big question is wether we will see consistent local storage support from IE8 following the same spec as the other browser vendors. The IE team have announced that IE8 will support DOM Storage, but that is only part of the overall local storage spec (ie the Storage object described above only).

Overview of Current And Future Support




 

Gears

BrowserPlus

Firefox

IE8

Webkit

ApplicationCache

soon




detect onLine





LocalServer




Storage



Database


Threading



SQL