ssafejava

I have the same issue with space on a 3-monitor setup. I simultaneously use Chrome, the Chrome inspector, an editor, terminal, Skype, an IRC client, sometimes Firefox, Finder, etc. There's always more things you can put up if you have the space. If I had 6 screens I would dedicate one to a dash, but with 3 it's better used directly for development.

So are cheeseburgers.

Great job, I've been listening to the soundscapes for a while. Just wanted to point out that the title tag at http://mynoise.net/NoiseMachines/tripOfMindNoiseGenerator.ph... is misspelled - 'od' for 'of'.

Thanks for making this!

The Closure Compiler on ADVANCED_OPTIMIZATIONS mode is a terrifying beast and only works on carefully-crafted code. It makes some astonishing optimizations, though.

I encourage JS developers who strongly believe in distributing source along with their webapps to use source maps instead of delivering slow, unminified code. They are only downloaded when a user opens the web inspector (no overhead for regular users) and provide transparent access to source as if it had been delivered instead.

Yes, you can use Node Buffers (which are not that bad), or JS native Typed Arrays (which are also not that bad but a little clumsy). Yes, in embedded systems, that might be really important so it can get clumsy.

It's not the best tool for the job. It's also not the worst tool for the job, and it's an extremely popular language. If it brings more people into the hardware space (which is its expressed goal), it will be a success.

You could - but V8 is actually much faster than Ruby or Python, and JS syntax is quite good for I/O. Better than that, a ton of people know JS and the more developers find this accessible, the better.

That's ridiculous and contributes nothing to the discussion.

Javascript is a good programming language, in that it's expressive, fast (much faster than Python), and more importantly it runs everywhere. No ecosystem can grow without developers, and the success of Node.JS clearly shows that developers like a system they can dive into without much prior effort, using skills they already have.

Tessel allows web developers to use skills they already have to do new things. How could that possibly be a bad thing? Just because Javascript has '==' and '===' and both 'null' and 'undefined' and {} + [] !== [] + {}? I swear, everybody seems to have seen the 'Wat' talk and thinks they're now experts on Javascript development.

Javascript, like many languages (even PHP!) can be written in a 'good' way and a 'bad' way. Thankfully, it's not very hard to write in a good way and it lends itself very well to I/O bound applications like webservers. Embedded devices, depending on the application, could also be very I/O bound, waiting on sensors, cameras, wifi, etc.

Javascript is actually one of the fastest interpreted languages in existence and thousands of new programs are being written in it daily. It's easy enough for a total beginner to use yet powerful enough to port Unreal Engine 3 to it. Get over your biases and recognize that JS brings with it something that Haskell, Scala, etc., will never be able to match: large numbers of ready developers.

http://www.google.com/preferences, second box down.

Obviously he's just joking, and most of the people in this thread got it. He's not incompetent, he wrote both Armitage and Cobalt Strike, and the latter has some really incredible features that are hard to find elsewhere. I'd say he knows his way around a computer.

Snarking about why he's root when he runs unzip does not advance the discussion and despite your efforts, it does not make you look smarter than him.

This is really funny - but the content shows the author's dedication to teaching (and learning) penetration techniques, even when it involves his own software. I would imagine that losing potential customers isn't a concern because the kind of people buying this software (generally) wouldn't run pirated versions. So instead, it makes a cool demo. Very cool, raffi.

I haven't done it with VirtualBox, but I have with VMWare - it is monstrously slow, until you install VMSVGA2[1], then it's pretty gravy. It's not as quick as native but it's massively improved.

Some applications render better than others; I see a nearly order-of-magnitude better framerate in Safari vs Chrome, which is too bad, but all in all it's usable and I do some development in it with few issues.

1. http://sourceforge.net/projects/vmsvga2/

Interestingly, they used to just blur their text with effect, and the actual text was available in the source. I am not certain what prompted the change, but they now screenshot the text, blur it, and put the screenshot (!) in the page, preventing view source snooping.

Since that started, I stopped reading Quora entirely and I always avoid their links. Occasionally there is some great content I can't find elsewhere, and I won't sign up to a service that is so abusive. This is a great trick. Thanks.

You're right, and I wish we had. Instead we were just sort of stunned by the underwhelming ending and the crowd filtered out very quickly (there was no "drinkathon", we were all too tired). It was Angelhack - I suppose, by the name, we should have known that investability comes first, hacking second.

Our team was tired out after all-night coding and really didn't possess the mental finesse at the time to walk the fine line between arguing "the results don't fit the spirit of the event" and "we are sore losers".

There wasn't much that could be done. According to the rules, all's fair so long as the code wasn't written until the hackathon itself, which is pretty much impossible to prove or disprove anyway. You can prepare as long as you want. There is a section about a "code review" but I doubt that was really done; IIRC we didn't even submit our code, we just did a demo & video.

The strongest complaint we could make was that it was strongly against the spirit of a hackathon, which is a difficult argument to win.

They not only share their name with the existing startup, they are that startup:

    The winning app makes it easy for consumers to find places to withdraw 
    small amounts of cash at a low cost, using businesses in their own 
    neighborhood and a PayPal technology that is very secure, said Alexander 
    Sjögren, who developed the app with Jose Pimienta and Osniel Gonzalez. 
    Sjögren is with the Miami company YellowPepper, which offers mobile 
    banking and payment solutions in Latin America. Pimienta and Gonzalez 
    co-founded Vinylfy, a startup catering to vinyl-record enthusiasts. [1]

YellowPepper is:

    About YellowPepper
    YellowPepper Mobile Financial Solutions provides products and services 
    that enable mobile financial transactions between financial institutions 
    (banks), businesses, and consumers in Latin America. With 1.5 million 
    users, YellowPepper operates in Ecuador, Colombia, Bolivia, Guatemala, 
    Peru, and Panama as a service provider for more than 50 financial and 
    non-financial institutions. For more information, log on to 
    www.yellowpepper.com. [2]

1. http://www.miamiherald.com/2013/08/25/3585797/hackers-emerge...

2. http://www.prnewswire.com/news-releases/yellowpepper-and-fun...

I've seen this before. I was involved in one where the winning team had been working for months beforehand (their website was registered > 6mo before the event), had prepared presentation materials far before the event including design mockups, and presented with nothing more than a pre-cooked video that was looked manipulated to show "working" code. None of us knew for sure, but it looked like they had just built static HTML pages and transitioned between them.

For those of us who had built working products, it felt more than a bit cheap. We saw some great code and very little of it was recognized.

I believe the issue is one of expectations and marketing for these events. They are pitched as "hackathons" and try very hard to attract engineers, as you simply can't have the event without coders. Therefore, engineers reasonably expect an event where the best code wins. After all, it's called a "hackathon", not a "meet & greet with investors" or even a "startup weekend". In the end, it just felt like the judges were putting themselves into the mindset of investors, and in that case, obviously the team that has prepared for months beforehand will win. But to the coders, we felt cheated, and that they had completely missed the point.

Could you explain why? The post below explains about how two users really shouldn't share the same password, and if they do, it's easily crackable - that makes sense. However, if you had a list of 100,000 passwords and did, say, a brute force attack of all passwords with letters, numbers, and special characters to a length of 8, without salted hashes you would be able to run that brute force once and grab every password matching the criteria. With salts, you would have to run it once per salt. Am I off on that?

True - you can also disable the globalAgent or change the number of pooled connections. Connection pooling was generally a bad idea (tm) in Node and afaik will be removed in the near future.

You're right, in my personal testing it does appear to be about 2x faster.

The big perf wins:

* Fewer box shadows

* Fewer gradients

* Fewer semitransparent borders (a big performance problem, especially in chrome - I've seen > 10x performance slowdowns when using rgba borders & border-radius: 0 - see Chrome's tracker [1])

* Simpler rules (fewer styles to cascade)

1. https://code.google.com/p/chromium/issues/detail?id=170882

No, it won't kill the process; it will simply terminate the connection. It looks like, from the C code, that it was intended to throw a 405 but somewhere in the process it screws up and terminates early.

It's a nice redesign, starting out. I especially like the cloud design up top. I'd just like to throw forward a few comments on it. Please take this as constructive, not as mean criticism.

* Design:

Unfortunately, it reeks of hip design gone too far - green text on a green background, grey text on a grey background, and amateurish construction. Removing the text-shadow alone from the alert boxes makes a big difference in readability.

* Structure:

The angularJS parts have already been addressed in another comment, but the most bizarre part is that there is minimal minification (.min.js versions of jquery & bootstrap, that's it - comments are still intact), no concatenation, and no gzip compression whatsoever.

I think it's easy to forget that jQuery alone is 90KB, bootstrap JS is 30KB, and bootstrap's CSS is ~125KB alone. The site is pretty simple; it could easily be trimmed down into something much faster. The use of jQuery is questionable, the use of bootstrap even more so considering how simple the layout is.

The pubsub module that pushes new inbox data is pretty great though.

* Content:

The content pages look great. The little transitions are nice. I like the new copy as well; it helps cement the point that this is not a serious security product and it should not be considered as such.

Overall, while it's a nice change, it may be a bit more flash than users are actually looking for. The massive assets package makes the actual email page huge - jQuery, Bootstrap, and Angular, just for such a simple page? Combined with web fonts, the total payload is well north of a half meg. Intro transition animations serve to make the perceived time to displayed content even longer.

A second pass with a proficient JS developer and a keen eye for readability would do a lot for this site.

Is this at all related to the Android-streaming software on http://www.appsurfer.com/, or is just a similar idea on a different platform?

It is certainly most of the way there now - the sensors are fantastic - and will be absolutely revolutionary with a higher-resolution screen and the addition of some yet-to-be-invented control schemes.

The paperwhite is a nice display, and part of the benefit they claim is that the light guide combined with a matte screen reduces the amount of backlighting needed, thus improving battery life. That may be - but another big factor is the relatively anemic chip compared to phones / tablets / laptops.

All that aside, I really wish this kind of deliberately misleading comparison would die:

http://g-ecx.images-amazon.com/images/G/01/kindle/dp/2012/KC...

Why are laptops and tablets and smartphones measured in raw hours, while the paperwhite is measured in weeks, where one day is half an hour? And then why plot them on the same graph, indicating that they mean the same thing?

A graph that wasn't intentionally misleading would show the paperwhite with a bar about 2x the length of the smartphone's - in practice, it gets about 11 hours at full tilt, and about 28 (that's 56 days * .5 hours per day) when conserving power.

ExtJS is widely used on government systems and has been for years. If you want to deploy a rich web application that can handle large data tables with infinite scroll, filtering, sorting, etc., and run it all on IE >= 6 ExtJS is your only feasible choice.

$300 is about 3 times what it should be, in my opinion. It's not much more than a fancy USB hub with audio & a NIC. USB 3.0 hubs with NICs are about $50-60, or one could easily use a regular USB 3.0 hub and attach a USB NIC, sound card, etc. Perhaps not as clean but a hell of a lot cheaper.

Even worse, the price is not really $300 - in order to use it, you'll need a thunderbolt cable which is nearly $40 (!).

There are few to no storage solutions that can benefit from thunderbolt over USB 3.0 and the whole ecosystem reeks of greed and vendor lock-in. No, thanks.

I agree - and this is what dissuades me from buying one. While the industrial design is indeed cool I'm not convinced that faster phones won't be available at the time of launch; this product has a very significant number of engineering challenges ahead of it, not the least of which is software.

If there is a 2nd- or 3rd-gen Edge I will be very interested, but today's state-of-the-art ARM quad is not enough for the tasks I usually run on my laptop. If it can't replace my laptop, then contributing to this project is just throwing $600 (or $830!) sight-unseen into a development black hole that could be months late.

In these sorts of situations contributors are almost never reimbursed for delays. By the time this launches there will be yet another generation of Intel chips, ARM chips, and flagship Android/iPhone devices. It just doesn't make economic sense.

I appreciate what they are trying to do and I don't know if there's a better way. But it's quite a risk to shell out that much for a toy that may not really be that useful in this iteration.

Yes, I've run into issues with things running differently in an async environment (dev) and a sync environment (prod). To mitigate the issue I now throw events at key points in initialization and wait for those events to continue. Has solved my problem so far.

Using r.js in development isn't the worst idea. It's worth seeing how long it takes in order to make that decision. Compiling tpls is much faster (grunt-contrib-jst) and adding that to your grunt watch & including it directly is a good way to save time. I think it takes a long time on my end due to the complexity of the dependencies. I only include exactly what each module needs so some dependencies may be as many as 6 levels deep, or more (haven't really checked).

SPDY makes a big difference for me (big enough to ignore the problem for now) and I don't mind using a self-signed cert in dev.

EDIT: I hadn't been compiling tpls using JST in dev until I wrote this post - a great side effect is, it actually shows me now where the errors in my tpls are! Previously any tpl's stack terminated at the code that ajaxed in the tpl. This is far better for debugging and brought my DOMReady time down to about 1.75s.

With requirejs, I run into the `mismatched anonymous define() module` issue when using concat-sourcemap. The "correct" way around it is to use r.js, but it takes about 2.5s to compile that way, which happens to be more than it takes for ajax to work its magic locally.

Running SPDY locally helps a lot. Even with all those files I hit DOMReady at about 2.7s with no concatenation.

The workflow might need polishing, but tools like SublimeInspector are not the answer. They are miles behind the Chrome Inspector. Try it if you're not convinced.

The Chrome team has shown that they are very interested in moving the Inspector forward and have succeeded in integrating local files access via the editor, SASS support, Source Maps support, and a lot more. It is to the point where it would not be crazy to consider building a site entirely within the inspector. While the editor is not as good as others, you do gain simplicity and the ability to patch running code. The workflow is getting better.

Writing a great inspector is the hard part. Comparatively, writing an editor should not be as difficult. Chrome built the inspector first and is circling around.

The only integration I would really care to see (perhaps via ST2 Package Control) is the ability to directly pipe into the Inspector and patch running code. For large projects, especially in development mode, it can be a drag to ajax in >200 source files (even from localhost) and refresh every time you make a change.