opening jbidwatcher

Subscribe to opening jbidwatcher 6 post(s), 2 voice(s)

 
Avatar Mathieu Lecarme 3 post(s)

I’d like to help one of my best tool : jbidwatcher, but the state of the source code is not nice for participation. It’s classical, one developer, 5 years of code.
If jbidwatcher wonts some contributed code, it should follow some modern pattern :

  • classes in hierarchical folders
  • junit tests
  • extract swing code from the engine
  • injection tool like Spring or Guice, separation of interface and implementation.
  • event oriented extensions.

With this, evolutions can be very easy :

  • client/server, for an headless no stop sniper for night shot
  • server in json, client in XUL for Firefox integration
  • events caught with Growl on osx for non obstrusive warning
  • translation by no coder
  • toolbar warn for tiny jbid
  • easy evolution of the engine when eBay change its pages
  • test for other implementation of critical performance part of the engine : time syncing and snipe
  • sms or similar trigger when a snipe is done
  • tags for organizing auction for organisation
  • web version for nomad sniper
  • native interface
  • stat analysis with tag or ebay search pattern, for price estimation
  • scripting with javascript or other languages

anything you wont!!

The first step should be svn migration, for easiest file renaming.
I’ll be proud to help you to migrate to Spring or Guice, and then doing growl plugin.

 
Avatar Morgan Schweers Administrator 1,204 post(s)

Greetings,

I’d like to help one of my best tool : jbidwatcher, but the state of the source code is not nice for participation.

I started writing JBidwatcher when I was learning Java (coming from 13 years of assembly, C and C++), and made some stupid decisions that CVS (the only free source control at the time) and inertia have made worse. I know quite well that they need to be fixed, and it’s being worked on (and many of the egregiously bad ones have already been fixed in a private branch). That said, I’ve been doing various forms of professional software development for 20 years. (whoa… It really has been 20 years now… crap, I’m old…) and one thing I’ve learned is not to make changes for changes sake. Every decision will be focused very specifically for the betterment of the user experience.

A great deal of your suggestions have already been done, starting with moving to subversion and packaging the classes properly, but the CVS tree is the source of the 1.x series, still, and so the recent changes are still needing to be done in there. I’ll open up the subversion tree once I’ve gotten it fixed up and working with the very core of the ‘Next Gen’ feature set I’m working on (as well as migrating up the changes that are happening to the CVS branch over the last few weeks).

injection tool like Spring or Guice, separation of interface and implementation.

Just to note, Spring will not get included. I have a good bit of professional experience with how bad it and Hibernate are. :( Maybe Guice is better, but I haven’t explored it yet. I also find that many software developers use DI for no reason than that they think they should. It’s not really necessary or useful in a great many situations, and yet adds complexity and bulk. YAGNI is a good principle to follow here.

event oriented extensions.

JBidwatcher is already event-based, in a rudimentary fashion. (I.e. in a fashion that worked with Java 1.2, when the original code was written.)

tags for organizing auction for organisation

Try right-clicking on a tab, and selecting ‘New tab’. You can create multiple tabs and organize items that way. Searches can also have a ‘target tab’ which they’ll create if they get any items returned from the search.

It’s classical, one developer, 5 years of code.

It’s been about 7 years of development, actually… :)

Seriously though, I’m sure you are passionate about some of this stuff, but you have to understand that I’m equally passionate about shipping a streamlined, simple to use program. Adding a library like Spring adds around 2MB to the file, for no end-user benefit. I used nanoXML early on because in Java 1.2 there wasn’t any XML support and Apache’s Xerces is/was stupid-big, which is completely unnecessary for simple save/load functionality.

Your icon suggests you’re a Linux user (which I am as well) so it probably seems easy to you to tell the end user to download things like the Spring or Xerces .jar files, or the latest JRE, and install them in the right location, and it’ll all work well. For most users that just won’t work. JBidwatcher is written to be usable by the average computer user. This means launch-and-run, no install. This means everything that JBidwatcher needs (except the JRE itself, unfortunately) is included with it in the .jar file.

My next version includes the use of the OneJar method of including libraries embedded in the .jar itself, and I’ve already given in and am including a pretty major library with it (Derby), because I can do very large user experience improvements on top of it. I’d desperately love to include JRuby, for example, so I could expose a simple set of data, and write much of the remaining code in Ruby but it’s 2.3MB. I am absolutely opposed to having a 10+MB download just for a eBay monitoring/sniping program. That’s coding for coding’s sake, not for the end-user’s sake. It might be something I’d play around with in my own branch to prototype features, but not something I’d expose to the rest of the world.

You may object, noting that Derby (as ‘JavaDB’) is included in the latest version of Java. However, not everybody HAS the latest version of Java. JBidwatcher currently works with Java 1.4, and in fact when a (very helpful!) user recently provided an early fix of some of the current issues, and built it with 1.5 totally innocently, about a half dozen users (of the small number that come to the forum at all!) noted that they couldn’t run it (and can’t upgrade for perfectly reasonable reasons). I might consider going to requiring 1.5 for the next-gen version of JBidwatcher, but that experience gives me pause, and I’ll be unhappy at leaving those users behind…

Shipping software to end users means working with the restrictions at their end of the system. This, and streamlining, means giving up some stuff. I won’t allow JBidwatcher to get bulky, unless that bulk is delivering real user value.

That said, several of the features you describe (the ones that aren’t already in place) are being planned. They just have to be implemented in a way that doesn’t blow out the size of the download, are compatible with older JRE’s, and are user-friendly.

Now, to your immediate question, the growl plugin… It’s been something several people have mentioned, and I’m curious what events you feel should warrant a notification?

That’s been something I’ve been looking into, trying to determine the list of events that are noteworthy from the user’s perspective, and I’d love some help coming up with that list.

— Morgan Schweers, Cyber*FOX*!

 
Avatar Mathieu Lecarme 3 post(s)

I’m a jbidwatcher addict since a long time, and when something with it goes wrong, first, I grumble, then, it’s an opensource project, so I watch the source to do it myself and submit a patch. But, with all thing that you explain nicely, patch can’t be done ligthly.
Just for precision, i’m linux worker, but osx user, and I agree that a java application must be a single jar without any dependency installed by hand.
Ioc is just a suggestion, when I saw swing and other stuff mixed, I thought that MVC is a nice pattern, especially for not swing developper.
I understand that modyfying jbid every time eBay change something can be painful, so external help can be great, but without breaking it all.
I’m happy that jbid nextgen is on way.
For me, the excuse of old java is not as simple. Java has to be installed in Windows, so, if you did it once, you can do it again, on osx and Linux, java 1.5 is available by default. But I agree, if you wont to bored users with a large download, you must provide a good reason, jbid nextgen can be this reason.
Just have a look at guice, it seems to be lighter (the jar is 396 Ko). I suggested Spring because I’m working with it for my job and know it quite well. But the size of the lib is not a good point for a tiny application like jbid.
I’m very curious about your secret work.
For me, flavored jbid can be nice, a daemon, a webserver and a rich application for example, swing in a headless computer hurts me.

It’s just a point of view, if Jbid can be trasnlated and simply hacked, it will make me happy.

For your growl question, it can be : “Don’t move, snipe in 10 seconds!”, “You miss it”, “You win it”, “Snipe is too low, more credit is needed, quickly”

M.

 
Avatar Morgan Schweers Administrator 1,204 post(s)

Greetings,

Just to cherry-pick for a moment…

For me, the excuse of old java is not as simple. Java has to be installed in Windows, so, if you did it once, you can do it again, on osx and Linux, java 1.5 is available by default.

Actually it’s OS X users who have the largest problem. I wasn’t specific, but Apple ties JVMs to their OS versions, and there’s a lot of people still running an OS X that doesn’t let them run Java 1.5. They literally can’t upgrade without upgrading their OS. :(

Because of this, I’m thinking that I’ll wait on releasing a version of JBidwatcher that requires Java 1.5 until a bit after Leopard comes out, so that I can say, ‘Hey…I can try to support the current version, and one version back, of your OS and Java version, but more than that and it gets hard to build a good product.’

That’s my plan, at least. :)

But I’m really looking forward to using the Java 1.5 language constructs in JBidwatcher. It feels so much better. :)

— Morgan Schweers, Cyber*FOX*!

 
Avatar Mathieu Lecarme 3 post(s)

I forget this OSX shame, sorry.

Just imagine, you get some POJO :
Ebayer

  • String login
  • String password
  • Boolean registeredAdult
  • EbaySite browseToSite
  • Integer snipeTiming
  • Set bids
  • Set multibids

Auction

  • Integer id
  • Url picture
  • String title
  • String description
  • Integer price
  • Date date
  • Status
  • String Seller
  • Integer shipping

Seller

  • String name
  • Integer note
  • Set auctions

Bid

  • Auction auction
  • Integer max
  • String comment

MultiBid

  • String comment
  • Integer max
  • Set auctions

EbaySite

  • Url url

With all services to store, get, search this pojos.
Specific services like Integer getLatency(), void refresh(Auction auction), List search(String query)

With that you can assemble differents jbidwatcher, even a jruby scripted one ;-)

 
Avatar Morgan Schweers Administrator 1,204 post(s)

Greetings,

Just for the fun of it, here are the list of attributes for an individual auction object.

  • identifier
  • insurance_optional?
  • fixed_price?
  • no_thumbnail?
  • current bid and buy_now price (and their USD equivalents)
  • minimum bid
  • shipping price
  • insurance cost
  • start and end date
  • Seller, high bidder, title
  • Quantity available
  • Number of bids
  • dutch?
  • reserve?
  • private?
  • has the reserve been met?
  • seller’s feedback (in number and percentage form)
  • Item location
  • Is Paypal accepted?

That’s not including the thumbnail itself, and the auction’s status.

There’s a LOT of stuff there to be tracked. Currently it’s all exposed already as a (pretty much) POJO. (It’s AuctionInfo.java.)

My preferred approach (again, for the ‘next gen’ of JBidwatcher) is to expose an API that turns auction objects into XML (already have that, it’s what’s used for saving), and then I can build an API on top of JBidwatcher’s already-existing faux web server, so that any app that wants to can talk to JBidwatcher via the XML-exposed API. (REST-y POX, not SOAP.)

This lets me do neat things like build widgets that communicate with JBidwatcher…

Sense make?

— Morgan Schweers, Cyber*FOX*!