Tuesday, January 26, 2010

toInstance in Google GIN

Couldn't find anything like toInstance in GIN, so I've developed one myself. Here is the patch against svn revision 135: instance-patch.diff
Usage: declare void methods named like "setXXX" in your ginjector:
interface MyGinjector extends Ginjector {
 void setSomething(Something real);
 void setAnotherThing(@Named("ID") int id);
 void setAlltogether(Something real, @Named("ID") int id);
 void setOptional(@Optional Object object);
}

Once all non-optional dependencies are set, you can call any other ginjector methods. It's that simple. I've included some tests which you can use as an example.

The curious thing is that you can chain your ginjectors together:
interface ParentGinjector extends Ginjector {
 void injectMembers(ChildGinjector inj);
}

interface ChildGinjector extends Ginjector {
 @Inject void setSomething(Something real);
 @Inject void setAnotherThing(@Named("ID") int id);
}

Note the @Inject annotation in the child injector. Now you can simply:
  ChildGinjector child = GWT.create(ChildGinjector.class);
 parent.injectMembers(child);

This is the pre-built version on google gin 1.0 with that patch:
GWT version < 2.3: gin.jar

Thursday, October 1, 2009

RPX is not a single sign-on solution

RPXnow is a great service, allowing you to sign in using most popular account providers (like Facebook, Google Accounts, Yahoo, etc.). But my experience with RPX was not that great: the problem is that you can't SHARE your sign-ups among websites. This was very disappointing when we started to use RPX on your website http://www.ecwid.com. We ended up creating our own single sign-on service, and that was not easy. RPX claims to perform as a proxy between you and OpenId & OAuth & other services, still it lacks the very important "smoothness" of OpenId&friends: you visitors still have to click button in RPX iframe to sign-in your website, even if they have already signed in RPX or any of third-party providers RPX supports.

We had a main website and a Uservoice forum, both using the same RPX account. When you sign in the main website using RPX, and then go to Uservoice, you find yourself not signed in there, until you press that dreaded button.

I understand that RPX is popular because of a "wow" effect, but I hope they will add support for SSO in the future, so that users won't be disappointed any more.

Sunday, May 17, 2009

Ecwid: Innovating e-commerce




It's been a while since last time I wrote. Not that I gave up my blog. I was just busy creating an insertable e-commerce SaaS solution called Ecwid. If I didn't do something wrong, you should see it just above this text.


It's a large project which was started at November'08 and came out with its first release at September'09. It features:

  • Pretty advanced product catalog designer
  • Integration with Google Checkout, Paypal Express checkout, Authorize.Net, 2Checkout
  • Shipping cost calculation using FedEx, UPS, U.S.P.S, DHL
  • Customizable CSS
  • Ajax everywhere (meaning it's fast)
  • E-goods, mail notifications, mobile version for SEO
Written in GWT (client side) and Java/Spring (server side).

Friday, September 19, 2008

PHP vs. JSP

There is a lot of speculation in the web about what is better - JSP (java) or PHP. Some claim PHP is insecure, which is not exactly true. Others claim JSP is hard to use or slow, which is also not true, and I intend to show why.

First, I want to rebut some of the myths around PHP and JSP.

Myth 1. "PHP is insecure". Some PHP programs may be insecure, because of their creators' negligence. These are tips to make your PHP programs secure:
  • Use PDO for database access. This will eliminate the risk of SQL injection.
  • Do not include session ID in URLs, because those URLs may be sent to other sites as 'Referrer' HTTP header.
  • Do not use shared hosting. There are a lot of virtual and dedicated hostings on the market starting from $10/month. Neither can you run Java applications on a shared hosting.
Myth 2. "JSP is hard to use". Not that hard. If you already know Java, you will invest maybe 3-4 more days to learn JSF or Struts, and this investment will return soon enough. You can use one of free or relatively cheap IDEs to master your JSF pages, and these IDEs are more advanced then those available for PHP development.

Myth 3. "PHP is not scalable". Neither PHP nor Java is scalable, because those are programming languages. A system can be scalable, not a programming language. Well, there are of course programming languages like Erlang, Forte and CUDA C extension, which enable scalability through parallelization, but PHP and Java do not differ in this respect.

Scalability of a system is its ability to increase throughput by simply adding hardware and not changing the source code. To make your PHP software scalable, just store all the state, including large files and session variables, in a database, and use database clusters with apache server on each node. Then use Cisco Load balancer or simple DNS round robin to balance load between nodes.

Myth 4. "JSPs are slow". You may take that impression because it takes some time for a new JSP to compile into a high-performing native code. First, a JSP is translated into a Java class file. That class file will be interpreted during the first invocation, but are incrementally compiled into native code during following invocations. You will be surprised how fast server-side JVM can be. It trades memory consumption for performance, e.g. by more function inlining.

There are, of course, ways to make Java slow, like using EJBs, but the same applies to PHP development.

Second, let me postulate the rule of the thumb to choose between PHP and Java for web applications. Use Java when at least two of the following is true:
  1. You do not have programmers with PHP experience handy, but you've got Java programmers;
  2. You want to use some existing functionality written in Java, which is unavailable in PHP. There are a lot of (persistence, messaging, imaging, protocol implementation, file format) libraries and frameworks for Java. Also, don't miss existing open-source applications: http://java-source.net. This may seem to be a controversial point, because there are more scripts and applications available for PHP then for Java. However, only few of them are stable or maintainable. In other words, when you choose an open-source software written in Java, there are much more chances that it will work than for the same functionality written in PHP;
  3. Your projected project size is more then 50K lines of code;
  4. You will have a heavily loaded web site.
Use PHP otherwise.

Finally, here are some tips for those who's already made his choice.

You've chosen PHP
Welcome to the world of non-professional development. Most of PHP scripts you will see in the web will not work. It is not a good idea to base a new project on an existing open-source or commercial code either, unless you need only cosmetic changes or addition of minor functionality. While existing software like PHPNuke, osCommerce and its clones, ShopScript, or even Joomla, may seem pretty, making a totally different software on top of them will most likely be extremely time-consuming. Drupal is somewhat better in this respect. Consider starting a new projects from scratch, eventually adding independent scripts and libraries like Smarty. At least in this case you will be able to use modern PHP at full extent (I mean, features like PDO, SimpleXML, new OOP model). You will focus on functionality, not on a lot of legacy code written for PHP 3.

You've chosen Java
Java is a bit messy about those APIs. Remember: JDBC, plain JSP, and JAXP are not for use. Their mere existence is either nonsense or serves needs of middleware builders. Use JPA/Hibernate for database access, JSF/Struts for web logic, JAXB or jdom for XML processing. Use MyEclipse or other IDEs to master your web applications. Do not write JSF by hand, like most PHP programmers do!

Good luck.

Tuesday, July 8, 2008

Teaching programming: two approaches

Hi!

Just as there are two types of programmers (career and geek programmers), there are two approaches to teaching programming:
  1. The first approach (I call it career teaching) dominates the teaching industry. It concentrates on programming languages, technology, frameworks and development tools. It will teach you the difference between Struts and JSF and how to use them in a Sun Java System Web Server or something like that. It is usually a boring, vendor-specific and narrow-thinking study; it is what most practitioners want and pay for.
  2. The second approach teaches you formal thinking instead of adopting a technology. This approach is often based on problem solving, because as long as you are faced a formal problem, the programming languages and technology do not matter. There is no common framework to find an optimal placement of rooks on a chessboard so that the sum of numbers in squares are minimized.
To be a true engineer, one must go through both types of learning. Although there is a lot of material, books and courses for the career learning, there is only few books that will teach you formal thinking. One of them is the book Information Theory, Inference, and Learning Algorithms by David MacKay, which is available both as hard copy and for download. Another resource is the Book of Programming Problems by me, not as splendid as the former, but its a start!

Honestly, it is not a book at all, and it does not match David MacKay's masterpiece even distantly, but it is rather a collection of programming problems with different level of complexity, all with solutions. You are welcome to propose your problems and discuss solutions (you can leave comments under each problem).

Microsoft Word plotting utility

Hi all!

There is my free function plotting macros for MS Word 2007. Take a look. It is capable of building function graphs and other curves right in the Word document. The plot itself is just a Word object, so that you can move the document from one computer to another, format or change the plot lines, change everything using MS Word tools.

Sunday, November 11, 2007

Recover a lost password from your web browser

If you forgot your web site password, you can restore it from your web browser, provided that the web browser is configured to store passwords, which is normally true. There are plenty of commercial password-recovery-tools out there promising to obtain and decrypt any password from any browser. Before purchasing one, I whant you to know that recovering a web browser password can be done easily and for free. In Mozilla Firefox, simply select Tools -> Options -> Security -> Show passwords.
The following is a brief instruction for browsers which do not show passwords (like IE I suppose). I personally used this approach to recover a password for my online banking service:

  • Install Java Runtime Envioronvent. You can download it here: http://java.sun.com/j2se/downloads.html
  • Download a Burp proxy, which is a free proxy software with an ability to capture and display http(s) traffic: http://www.portswigger.net/suite/download.html
  • Unpack and run the .bat file there. If you have a firewall on your desktop, allow the java application to access the network in the firewall popup window.
  • In Burp, switch the 'intercept on' button on the proxy -> intercept tab.
  • In your web browser, set proxy to localhost, port 8080. In Mozilla Firefox, for example, this setting is available somewhere in Tools -> Settings -> Other -> Network -> Settings. Check the radio box "manual proxy settings" and enter hostname 'localhost' and port '8080' for both HTTP and SSL connecctions.
  • Goto the login page in you browser and log in. The login form should be captured by Burp proxy.
  • In Burp Proxy window you will see the HTTP request list, from which the one marked with 'POST' is most likely the login request itself. Double-click it. You will see the raw HTTP request, starting with word 'POST' and blah-blah-blah. At the end of the request text there should be the login form data, containing your lost password, like the following:
ltmpl=default&ltmplcache=2&continue=http%3A%2F%2Fmail.google.com%2Fmail%3F&service=mail&rm=false&ltmpl=default&...
...hl=ru&GALX=b0&Email=D-----a&Passwd=12345&PersistentCookie=yes&rmShown=1&signIn=%D0%
  • Find the password field there. It should have the name Passwd= or password= or something like that. Whatever follows the '=' up to the '&' is you lost password (in this case, the password in 12345, which is, of course, a faked one :)).
  • Do not forget to restore you proxy settings in your browser :)
Apart of its low cost, the approach has an advantage that it will work with any web browser, as it tries to solve the problem on a network side and does not deal with passwords stored in browsers.