ninh

Sony appears to have patched it from firmware 4.06 and up. The adieu in the title appears to refer to bidding a farewell to the exploit rather than a codename for it ;-)

Great and insightful write-up nonetheless!

ninh

10년 전discuss

Phusion co-founder here (creators of the Passenger app server); just wanted to chime in and say that this article resonated a lot with our experiences with VCs and our ventures in open source. Even down to the "lifestyle business" remark. Like OP, I'd encourage first-time founders to talk to VCs when starting out just to get an idea of how they perceive your business. Yes, even if you don't plan on raising. You may walk away learning a thing or two :-)

As for RethinkDB; we loved it, and even wrote an article about it a few weeks ago, outlining how it could be awesomely used with Rails 5 [1]. Having tried to bootstrap a company solely around an open source product ourselves as well[2], we can't help but share their pain here a bit. For instance, and I'm just going on what OP has shared about RethinkDBs business model, we tried to build our business solely on support contracts initially too. That didn't work out great for us.

And it kind of makes sense if you think about it: the support contract is available in case your software is failing during critical operations, yet your main efforts in product improvements are to minimize those chances. So you may have two conflicting interests, and I think you will find yourself having a hard time satisfying both. Through product improvements, you're basically minimizing the probability that such a support contract is needed. That might make it more enticing to only get the contract whenever you actually really need it, and that moment might never come. Especially if you consider how many hoops customers have to jump through to procure something within the enterprise. I can imagine something similar happening for RethinkDB.

This was an important realization for us though: rather than charge for the probability of problems, consider charging for the product's merits instead. As much as it pained us to introduce a closed source premium version of Passenger a few years ago to do this, I can confidently say that it was the best choice we could have made for our open source users as well; it allowed us to have a sustainable income and allowed us to rapidly improve Passenger's open source core alongside the closed source version as well. So even though I commend OPs determination into keeping things strictly open source, I'd encourage him to look into a hybrid option as well. We wouldn't be around here today as a company if we didn't.

Lastly, seeing as OP is a fellow bootstrapper and a fan of Basecamp as well, I think Jason Fried put it best when it comes to VC monies: "if you start out by raising money, you get good at spending money, but if you start without money, you get really good at making money", or something like that :-)

[1] https://blog.phusion.nl/2016/08/04/using-rails-5-actioncable...

[2] https://blog.phusion.nl/2015/10/30/bootstrapping-a-business-...

ninh

12년 전discuss

As for (former) top tiers: you're forgetting Yang ;-) He was considered top tier in Arcade Edition too, and was nerfed considerably in Arcade Edition 2012 to the point many thought he was not tournament viable anymore. The game gradually went from favouring defensive characters to rush down characters, and now with Ultra Street Fighter 4, back to zoning/footsie characters: I believe Ultra Street Fighter 4 has seen the most diverse top 8 in tournaments (see Evo for example) from all iterations when it came to characters, which makes me believe that it is currently balanced quite nicely, meaning that almost all characters have a good shot at winning a tournament. Well, except for maybe Dee Jay, Honda and Dhalsim unfortunately.

For those wondering why there have been so many iterations of Street Fighter over the past few years: aside from introducing new mechanics and characters, SF has been "broken" a few times in the past with the discovery of so called un-blockable setups. These unblockable setups caused hitboxes to overlap in such a way that it would leave your opponent in a state where he/she could do nothing other than to get hit with an the attack. The only way to block it was to do it frame-perfect, which is incredibly hard to do considering the game runs at 60fps. Especially under tournament pressure :)

It was broken again with the discovery of so called vortex setups, which kept your opponent in constant 50-50 guessing state after being knocked down: will the attack hit from the front or back? It wasn't uncommon for even the aggressor to not know what side it would hit. A vortex like that could easily lead to stun, and a subsequent KO if you guessed wrong for more than 2 times. Talk about unforgiving right? ;-) Characters like Ibuki and Akuma benefitted strongly from this and almost allowed for autopilot gameplay. No fun if you were on the receiving side indeed.

In an effort to combat gamebreaking setups like unblockables and vortexes, Ultra Street Fighter 4 introduced the delayed wakeup mechanic which allowed you to mess up the timing of your opponent if they tried to do a vortex/unblockable setup. It's kind of a lazy fix, as I think it'd been better to just fix the hitboxes. Even though it does a decent job at combatting these setups, it also considerably slows down the pacing of the game as well.

As the article shows, some characters do better against other types of characters: zoning characters have historically been able to do incredibly well against grapplers for example by playing a keep-away game. Grapplers on the other hand generally tend to have the advantage against rushdown characters, and rushdown characters usually are able to blow up zoning characters. Considering that the game has been out on the market for a while, it shouldn't come as a surprise that most tournament players are able to play 2 or more characters from different "archetypes" at a high level. This "counter-picking" was historically frowned upon and considered a "cheap" move, but I believe it has become more accepted as of late due to bigger prize pots coming into play in tournaments.

I've unfortunately been able to infer how the article factored in some character specific strategies: divekicks can generally be mitigated with a fast standing jab for example, and some characters are prone to longer combo's due to larger hitboxes. It'd be interesting to see how this would affect their model as it is something that I think matters in matches: Dudley is able to do an extended bread and butter combo for example on Balrog(boxer)/Abel, which leads to not only more damage, but also more stun.

After playing the SF4 series for over 6 years, I still thoroughly enjoy playing this game in my spare time and in tournaments. I was pleasantly surprised to find out that some fellow startup founders coughTobi Lutke from Shopifycough are incredibly good at the game as well, and can't wait for them to improve the net code in Street Fighter 5. Probably has to do with being competitive I guess ;)

ninh

12년 전discuss

Because revenue != profits.

ninh

12년 전discuss

Multiple income streams is the best starting point imo if you don't know what you want to double down on. Getting $100k itself is not an easy task, let alone trying to get $100k off of a single thing. It's easier (and more pragmatic) to get to $100k by getting $5k on product A in YRR, $20k on product B etc... These things will eventually add up and need to be easily maintainable projects (as opposed to timesink projects). I wouldn't recommend writing a super complex app consisting of millions of lines of code for example that requires a lot of support towards your customers; instead, consider writing an e-book and selling it for $10-30 a pop. Or a SaaS that nets you $10 MRR per customer.

Another upside imo of this approach is that you can discern at a later stage which one of your projects is most successful and has the most chance of getting you to $100k YRR, on its own. This will allow you to decide if you want to double down on it or not.

Also, consider building things someone wants: I know, I know, easier said than done, but it's often a good place to start at what you'd like yourself. In a worst case scenario, you'll at least have 1 customer (yourself) ;-)

ninh

13년 전discuss

Disclaimer: co-founder of a company called Phusion who started the company in his final year of graduating CS... in Enschede, The Netherlands (a city you might have never heard of before, and that I wanted to mention just to underline that it's possible to create a company pretty much anywhere thanks to the internet).

I think what you're struggling with is more of a mentality thing. I used to think I was trapped like you (but then took a macbook to the knee ;-)), but figured out there were a few things I could do about it:

- Complain about it (i.e. stating the obvious) which would not solve my situation.

- Move to the states to found the company there, which would not solve the situation for future generations.

- Try to deal with it somehow, and try to contribute our little share in the hopes of cultivating a local tech industry.

We chose the latter, because we're the adventurous type I guess and would love to see NL get on the map when it comes to tech startups. Even though this arguably has made things a lot harder for us than they needed to be, we learned a lot by doing it this way. The absence of like-minded people was especially hard for us: startups tend to take a lot of time to set up and can be pretty lonely if you don't have people around you that are going through similar stuff as you are. We eventually found a precious few of them in Amsterdam, with whom we regularly have coffee with up till this very day. Now, Italy is a lot larger than the Netherlands so I suspect there are more startups there as well; you just need to find them, perhaps this post will contribute in finding them.

Unless you're on an applied university, from my experience, programming isn't really taught at CS at university level. Instead, the focus is put more teaching you "a way of thinking" and it assumes that you'll pick up things like programming in languages like Python/Ruby, and learn about REST on your own time.

I believe you might have enrolled into university with the wrong set of expectations: during my entire CS curriculum, I've only had 2 programming courses, but they were focussed more on the paradigms than elaborating syntax; the latter things were assumed trivial and had to be figured out on your own time.

It's easy to get caught up in things that an "environment" is doing wrong, and to lose sight in what it does right. Personally, I can't imagine living somewhere else at this moment in my life than the Netherlands for example, where we have pretty good healthcare, affordable universities, and so forth. If you're unable to come up with a list like this, then it might indeed be a good idea to consider moving to another country for a little while and see if the grass is indeed greener on the other side. Shouldn't be too hard as an EU citizen right? :)

ninh

13년 전discuss

[email protected] for general inquiries.

ninh

13년 전discuss

These pictures are beautiful, and I wish I had thought of doing this as well. As someone who has seen this disease run its course on a loved one, they brought back a lot of memories. Especially the effect chemo and a mastectomy usually has on that someone and their family. From losing their hair to having a swollen face due to retention of water, to being bedbound etc. The last 3 pictures are unfortunately all too familiar.

ninh

13년 전discuss

(Full disclaimer: BubbleConf co-organizer)

And tickets have been available for roughly 3-4 months now ;-) If you were among the earliest, you could've gotten it at as low a price as EU 160 inc VAT. And even then this conf is run at a loss. (We're not in it for the money though, we want to grow and inspire the EU startup scene instead).

Who knew conferences were expensive like that right? We certainly didn't when first working on this, so I can't blame you that you seem surprised. The best way to explain/understand is by trying to organise a conf first-hand, it's definitely been an enlightening experience for us.

Just to give you an idea of what is involved:

- Rent an awesome venue for your awesome attendees

- Designing the entire conf

- 300+ Badges/lanyards/programmes/posters/etc...

- Website / Payment systems/checkin systems

- On floor staff of about 12 people for the entire day

- Hire camera folks for video registration

- Hire photographers

- Hire audio technicians and technicians to operate projectors etc...

- Flying over international speakers (and amazing speakers they are indeed)

- Provide lodging for those international speakers

- Organizing a speaker dinner

- Make nice food available for your 300+ attendees during the two lunch breaks.

- Have a nice party at the end with drinks and laughter.

This all culminates into hundreds upon hundreds of hours of work (if not thousands, I lost track somewhere along the line), and many tens of thousands of euro's. The only reason this doesn't reach the 6 figure mark is because of sponsors and the voluntary work we put in this. I hope that after hearing this, EU 300 doesn't sound that crazy anymore ;-)

ninh

13년 전discuss

Universities tbh are more for meeting likeminded people nowadays: most of the stuff taught at CS can be learnt on your own given you're disciplined enough.

Just to underline some of the points others have made, here is a short list of things I found most valuable from my CS degree:

- Algorithms, Datastructures & Computational/space complexity (ADC). <-- This one is huge imo and will allow you to discern efficient code from inefficient ones.

- Discrete Mathematics. It's the lingua franca when talking about CS and you will need it to understand ADC for example. It introduces set theory, graph theory and so forth, which are used in ADC/AI etc... to describe and solve problems.

- Linear Algebra: if you ever want to work with 3d stuff, this one will be essential. It'll also work out nicely for 2d work, and seeing as you mentioned you've got a knack for UI work, you probably will appreciate this one. It'll allow you to get an understanding of for example affine transformations etc... You will need a computer graphics course too, but this is definitely a prerequisite course to do those.

- Probability and statistics. I really hated this course (it's also one of the harder ones coincidentally), but once you "get it", you really do "get it". Ever wondered how gesture recognition works? Or how spam filters work? Well, the math required for this will be addressed here, together with the following subject.

- Artificial Intelligence. Extremely useful if you're interested in game dev, or just want to learn to solve problems in a smart and efficient manner. It combines ADC with discrete mathematics with probability & statistics.

- Calculus. If not for the math, it'll definitely make you look at things in a different way, which imo in turn, contributes to your way of looking at problems. Partial derivation / integrals and how it can relate to 3d surfaces for example. And let's not forget taylor series etc... It'll give you an idea of how mathematical functions such as sin(1) etc... can be implemented etc...

- Operating systems, Computer Architecture/organization. Essential for understanding what happens under the hood. Allows you to reason about what the best code path is for solving a problem. Should you use the GPU for example instead of the CPU etc... and if so, why? etc... It also introduces models such as finite state automatons etc... which are also applicable in language processing for, say, compilers.

And that brings us to the last, but certainly not least subject, my all time favorite: - Compiler construction. Gives you an insight in how languages are being processed, and how to design your own language and build a compiler for it. It should also give you additional insights on how runtimes/virtual machines work.

The software engineering courses were more about processes, philosophies and patterns etc... and even though they're definitely useful, I think most experienced software engineers have already "got this". Either via books, company policy/culture or via experience.

Again, these are my experiences, YMMV :) Good luck!

ninh

13년 전discuss

Congrats to Geoffrey and his team! PeepCode's screencast have been a huge time saver for us and I hope this acquisition will only allow them to do even more awesome things.

ninh

13년 전discuss

+1

@topicstarter: consider taking a break. Things usually make more sense once you've taken a breather and focus on other things in life than "doing a startup". It can provide you with a new sense of perspective on your current situation (i.e. it's not as bad as you think it is).

Moreover, creating well executed solutions is a hard thing to do, period. Try adjusting your goals on what you hope to get out of your startup: not only financially but intrinsically as well. Setting the bar too high on day 1 is the same as setting yourself up for failure. Taking things one step at a time works much more motivating and allows you to iterate to your desired end-goal.

Also, consider reading up less about what others do. In particular, consider reading up less about other people's successes and so forth. They can easily create this feeling of "being a failure" for not having been able to achieve that just yet. Startups tend to fail more often than not, although I wouldn't necessarily be too comfortable to use the word "fail" in this context: it's often a necessary thing to learn what one did wrong and how one can improve. In that sense, you might want to take another look at your undertakings of the past few years :)

ninh

14년 전discuss

Nice, not familiar with Pixate, but I wonder if the author has considered making this work with SCSS too :) That'd be pretty bad ass if it could be done fairly easily and would be nice for styling nested layouts.

ninh

14년 전discuss

You're referring to implication then, i.e. P => Q <=> !P || Q and in that case, I definitely agree. ;-) That's also why I started my comment with a propositional "if" on how one could define "no meetings" and "no communication" to show that there is something to be said for the P != Q interpretation.

In short, I believe neilk should have used => instead of !=. Or just plain english. ;-)

ninh

14년 전discuss

If you define "No meetings" as !meetings, and "No communication" as !communcation, which to me sounds reasonable, then they are in fact equivalent.

This becomes apparent when you create a truth table for it:

    !meetings != !communication

    meetings | communication | expr
    F        | F             | F
    T        | T             | F
    T        | F             | T
    F        | T             | T

This is the same truth table one would get with "meetings != communication" so they should be logically equivalent.

ninh

14년 전discuss

^ This. It depends on the kind of software you're interested in writing. Algorithms, datastructures & complexity analysis is imo arguably among the most valuable of the bunch due to its broad applicability. This is for instance particularly useful when writing software that needs to scale and perform well, e.g. server/system software.

In short, I feel there is merit to each CS course but want to underline that it's information you can self educate yourself on should you be so inclined to do so. Attending a CS major however helps with keeping one motivated. That brings me to imo the most important point of attending a traditional CS major: meeting fellow CS'ers to do a startup with :) I think that has been the most valuable CS experience for me. That's something I kinda miss with this "new era" of online courses.

ninh

14년 전discuss

It's quite simple actually. If your business is not dependent of consultancy, i.e. it's not your primary source of income, you'd do yourself a disservice by not TRYING to charge a significant amount: you never know who might be willing to pay it. In particular, an amount that would be at least the lower bound of what you expect your app to generate in terms of income on an hourly basis.

After all, you're not dependent of those consultancy funds, but if you find someone who's willing to pay the requested amount, it's win-win. You're basically put in a unique situation where you're able to experiment with that and you might end up with a few interesting contacts as well by doing so.

ninh

14년 전discuss

moleskine, which is kind of weird though if you think about it: any other sketchbook is likely to be a magnitude cheaper and would for me probably suffice the purpose of doodling/sketching just as well. I do catch myself subconsciously factoring this in when sketching/doodling though by using the paper surface more errr... economically ;-) The best reason I could think of is the leather cover; it holds amazingly well in my overly packed backpack :)

ninh

14년 전discuss

Aaah, we initially considered stacking the open source version against the enterprise version in a comparison table, but due to some previously made design choices, were unable to fit the column properly in time! Instead, we opted to drop that column in favor of being able to launch today and potentially fix in a future update.

Considering the feedback from this thread, it definitely looks like something we need to fit back in and will be among the things we'll work on for the next iteration/deploy. Thanks for the feedback and kind words, it's much appreciated seeing as we've been working on this for a while now; it easily becomes hard to look at things with a fresh pair of eyes after a while, which is definitely needed for giving a good first impression imo.

ninh

14년 전discuss

We protect through our license, not through engineering. There is no copy protection implemented in Phusion Passenger Enterprise, so technically speaking, we can't stop you. Instead, we trust that our users won't abuse this fact.

Submissions

Debian and Ubuntu packages for Phusion Passenger

The new Rack socket hijacking API

Phusion Passenger 4 Technology Preview: Out-Of-Band Work

Why Rails 4 Live Streaming is a Big Deal

Phusion Passenger Enterprise released

Objective-C for Ruby developers part 1

comments