mark242

  def complete_items(...) = bin.items.flatMap((item, v) => 
    expectedSymbol(item).map(nonterminal => 
      grammar.nextValue(document, item.origin, bin.binindex, completed_binindex, nonterminal, item.ruleindex, item.dot, v, value)
        .map(nextvalue => (item.inc -> nextvalue)
    )
  )

  var removeGrayImage = function() {
	$("img").each(function(idx, el) {
		var canvas = $("<canvas/>")[0];
		canvas.width = el.width;
		canvas.height = el.height;
		canvas.getContext("2d").drawImage(el, 0, 0, el.width, el.height);
		var pixel = canvas.getContext("2d").getImageData(1, 1, 1, 1);
		var r = pixel.data[0];
		var g = pixel.data[1];
		var b = pixel.data[2];
		if(r == 183 && g == 183 && b == 183) {
			$(el).css({opacity: 0});
		}
	});
  };

Give it a snazzy name. Maybe.. "Livewire".

http://www.datacraft.com/livewire.html

Thanks for the reply. Very thoughtful. I have a couple of points.

"What we'd hoped to accomplish, and fell short on in the end, was a way for developers with non-traditional backgrounds find gainful employment."

First: I think you'll find that a lot of developers have "non-traditional backgrounds" (where by "non-traditional" you mean "didn't graduate in CS", I'm guessing). Is a person with a MS in CS going to have an easier time finding a job in, say, Iowa? Maybe they are, maybe they aren't. If someone is having a hard time getting their foot in the door in Iowa because they don't have a degree, giving them +K isn't going to help much (and I'm guessing you found this out from the companies you contracted with).

Second: "There's a huge disconnect between what developers want and what companies want. You're going to have to reach out to developers who fit." I know this is too late, but that statement should have been front and center on your site. You're hiding the true intentions of your application behind this layer of developer competition, when in reality "We can help you find a job" should have been your number one point. (In the language of your site, "Discover" should have been front and center, and "Compete" should have been 86'ed.)

Last, the remote thing: I don't think that there is -- yet -- enough of a market for recruiting agencies for remote workers, especially at your typical Fortune 500 company. Office culture is ingrained in this country, and probably will be for another generation or two. If someone is in a "weird location" and they're unwilling to accept a relocation offer, that's (currently) a massive hurdle in their career growth, and as a talent agent it's up to you to tell people this. It would be like a rookie in baseball with a no-trade clause; that doesn't work.

Anyways, good luck in the future and all that; I'm sure this was, if nothing else, a great learning experience.

It's rarely a good thing to read about a company closing its doors, and I hope that you guys have more luck in your next venture, whatever it may be.

I suspect that you had a really, really tough time getting companies to pay you for placement (that is where you make your revenue, right? I don't see any other way). You've created some strange hybrid of, essentially, a gamified resume', and while the little graph is a neat trick, you probably figured out pretty quickly that companies with the money to throw at recruiting services simply do not care one whit about how many internet points a potential new hire has on some random site.

As a hiring manager, I can tell you what I'm interested in when seeing a potential new hire: a well-written, concise resume, links to code samples (whether on Github or elsewhere), and how well they're going to work with the rest of the team. Work for Pie appears to take the long route around coming up with an executive summary (of sorts) for just one of these three attributes. It seems highly impersonal and I'm surprised that you got any developers to sign up for it even with the promise of free internet points.

Also, I'm sure you found out the hard way about how intensely competitive the whole third-party-recruiting game is. It is not a market for the weak of stomach; I cannot tell you the number of phone calls I get as soon as I post an opening, and nearly all of these calls are extremely, extremely aggressive. Here's the average phone call: "Hi Mr. M242, I'm Recruiter from ColdCallCorp, and I saw you had an opening for a developer, I have a person coming out of JustShutteredStartup and she did X, Y, and Z, which I noticed on your listing, she has N years of experience and is extremely excited about coming to work for you, when can I tell her you're free to interview?" (This is without me saying any words past "Hello".)

In practice, we have seen much much _less_ garbage created by our Scala code. The use of objects in Scala encourages static method creation, and there's so much boilerplate Java junk that your Scala code just doesn't need.

Scala does not run slower than Java. Period. Additionally, the very nature of Scala and Akka allow you to be much, much more efficient on the hardware you're using; if you're writing Java code that requires, say, 100 application servers, often times you can get away with half of that if you're writing good Scala/Akka code (and because of the nature of Scala, it's much easier to write good, solid code than it is in Java).

You're making the case that Windows ME sucked, Vista sucked, 7 was good, and 8 sucks.

You're absolutely missing the bigger picture, which is this: nobody cares about operating systems anymore. Everyone, I think, finally gets that the function of the operating system is to get out of the way of the application that the user is running. iOS and Android are perfect examples of this. Everyone who argues about operating systems now talks about contextual menu this, flat button style that, driver update this, without realizing that the typical primary use of a computer these days-- desktop, laptop, tablet, whatever-- has nothing to do with the operating system and everything to do with HTML and JSON.

You talk about how a lot of people bought iPads thinking that it would fully replace their PC, and now they're disappointed. I would argue that, based upon the rate at which mobile web traffic is increasing, those people are anything but disappointed.

I have serious doubts that there will be a Windows 9. There will simply be no market for it. No kid today is asking their parents for a Windows Phone or a Surface. None. When those kids grow up, Microsoft will simply stop existing save for the Xbox.

The reality today is that Microsoft does not have the engineering talent that they used to have, and their design talent has been completely drained. They simply are not a 21st century software company anymore. The marketplace perception of Microsoft now is that they are a dinosaur that also makes a gaming console. Period.

They may very well have a functional competitor to EC2, but I cannot think of one serious company that is choosing Azure over AWS, or Rackspace, or even Digital Ocean or Heroku. The Azure Case Studies page is an absolute joke, a mockery of what you would expect from a behemoth as Microsoft. The simple fact is that Amazon completely owns the market that Microsoft is trying to break into. (This is especially funny given the years 1992-1996)

They may very well have a functional competitor to Google Docs/Drive/Apps/whatever it's called now, but again, Google is totally dominating that market (crappy updates to Gmail aside). Microsoft is stuck on the outside looking in, and anyone who is starting a company, given the choice between Office 365 and Google Apps, they aren't picking Office anymore.

Windows Phone is a joke and I'm not going to devote any more words to it.

Windows 8 isn't even worth any discussion.

The reality is, is that as kids in college today enter the workforce with their Android or iPhone, and Gmail/Gdrive, and knowledge of AWS, the need for Microsoft (which you have to admit, MS has been coasting on for probably 15-20 years now) is evaporating. If all Microsoft ever tries to do now is play catchup to Amazon, Google, and Apple, they're won't necessarily be squashed, but they'll just become irrelevant.

Got a good compromise between the two? Send a pull request and I'll get it in.

Here's a few responses. The design at a wider width is, okay, let's call it suboptimal. Send me a pull request with a fix for 1600px screens and I'll gladly put it in. Testing was originally done on a non-maximized desktop, along with an iPad and iPhone. (If something looks strange on Android, send me a pull request for that fix, too.)

MailDrop was designed to be a friendly clone of Mailinator, with a little different architecture. It isn't going to approach the speed of Mailinator, but I'd like to think the extra functionality makes up for it. You can point any CNAME or MX toward MailDrop and it will accept messages; the system doesn't care about the recipient domain at all.

If you don't want to browse through the (poorly-formatted; what's up with that?) source, here's a quick roundup of the architecture. MailDrop runs in two JVMs and uses Redis as its datastore. One JVM runs the SMTP server (written in Scala, using the SubEthaSMTP Java library and a collection of custom Akka actors) and one JVM runs the webserver (written in Scala/Play).

Performance should always be IO bound; the Akka actors use very little CPU overhead. If you're finding that you're running into bottlenecks, spinning up another JVM is pretty easy. Right now, maildrop.cc is running on one small EC2 instance for everything; if it explodes, I'd probably just add another instance for another SMTP server.

You'll notice that there's no way to actually send mail from MailDrop. That's by design-- the moment you can send e-mail from a service without authentication, spammers are all over it. Hence, no forwarding messages, no forwarding inboxes, etc. MailDrop is designed to help fight spam.

Thanks again for the responses!

The mortgage tax deduction provides a huge amount of what turns out to be disposable income for the middle and lower-middle class. Take that away, and the ripples in the economy would be massive. Similarly, all current house prices would be trimmed by at least 20%, and most likely more than that due to how the tax deduction is able to help with principal payments. If we have another 20% trim of house prices across the board, you're looking at -- at the very least -- a return of the great recession. As mortgage rates are already at their lowest point, there's not much further down they can go to compensate for the sudden lack of demand that will occur.

Spending money gone. House price chopped in half, sending more people underwater. Mortgage interest rates nowhere to go. That's a trifecta of disaster.

First-- what you're really testing here is the Jackson library. A majority of the cycles used in your application are being burned in that toJson call of an array of objects. This isn't a fair test compared to the servlet implementation because you're calling Jackson against a map in the Play example, versus against a simple String in the servlet example.

Second-- you are running database calls serially, and those are blocking. Considering that you're using the more-or-less default Play/Akka configuration, there are only enough threads as you have available processor cores. I would start by increasing the parallelism-factor and parallelism-max to be higher, so you'll have more available threads. More importantly though, the database access should be wrapped in a Future, and you should be returning asynchronously. This should speed up the application by a huge amount.

SQL("select * from person where id = {id}").on("id" -> myAgeVariable).map(row => MyPersonObject(row[String]("name"), row[Int]("age"))).toList

...returns you a list of MyPersonObjects. No need for JPA bindings or any other annotations. Based on type safety, you must have the method MyPersonObject.apply(name: String, age: Int) or else the compiler will error. It's a great way of catching SQL funkiness inside your IDE.

It's too bad that the presentation doesn't include sample Scala code for Play; imho this is the number one reason to use Play. The saveRating() controller method that they use as Play's example, which is some twenty lines of Java code, could be done in one or two lines of Scala code. Similarly, running a job in Play is essentially just spinning up an Akka actor and scheduling messages to send to it-- very very straightforward.

Play has been extremely easy to work with, especially with writing Scala code, and it's much more lightweight compared to, say, the Lift framework.

The PAN data -- the cookie -- is encrypted in transit, and if it's encrypted at every point in Santander's network then technically they could be compliant to the letter of the rules. I have no doubt that a company so dumb as to store your PAN data in a cookie is probably breaking a myriad number of PCI-DSS rules, but the card-data-in-cookie may not be one of them.

You say that this could be yet another datapoint for the IRS to collect taxes with.

The example you use has the number of Foursquare (and I'm sure Facebook) checkins within the statistical amount of noise for the actual number of people who visit the venue.

The example you give in this thread is a corporation who undoubtably has a team of dozens if not hundreds of tax attorneys on staff to ensure that the company pays exactly the amount of tax they owe, at the federal state and local levels, and not one cent more or less.

But let's take it a step further, and say that Joe's Ajax Factory in East Blogentry, California is skimming off the register. Okay-- so now you need some city clerk in East Blogentry to run this magical data analysis software which says Joe isn't putting enough into the city coffers?

Again-- this is a laughable idea. Even if the software were completely accurate (which is impossible) and admissible for a local tax audit (which it wouldn't be), and the amount of local taxes that you recouped were more than the TCO of this software (which it wouldn't be), you're assuming that the unscrupulous store owner (undoubtably laundering money a la Office Space) would just sit back and take it?

Come on, seriously.

I'm sure nothing bad at all would happen upon people reading that headline.

Approximately 6.8 million people visit the Eiffel Tower each year.

It doesn't take a math major to realize that this is a laughable idea.