Today we are open sourcing Hyper. It's built on the ideas presented in From Tomorrow Back to Yesterday and Anders Murphy’s demos. It's early days so expect things to evolve but we welcome contributions and ideas from the community
Urbint engineering is building a cutting-edge data ingestion and machine learning pipeline for exposing the hidden intelligence within urban data.
We're looking for Senior Engineers to join our team. We use Haskell's expressive type system to build distributed, concurrent, performant and safe systems. Rust is also used for when systems level programming is of benefit.
In my mind there are a few reasons, but indeed it could definitely be implemented with a flat file. Sometimes you aren't guaranteed write-access to a file on the system, especially if you're using a PAAS like Heroku. That also complicates things if you want to build something to view/edit the data in an isolated instance. These are just the reasons that come to the top of my head, but in reality you're right, this could be finessed to be done with just a flat file.
I haven't tested on a laptop be honest. Interesting point. What is atrun? I'll do some research and see if I can do anything about it... For reference node idles at about 3% CPU on my dev-box.
Very cool. How robust is the english parsing? For example, would it understand something like "The first wednesday of every month"? Either way I will definitely check it out.
See above for Mongo vs Redis. As for "feature completeness", this is a pretty feature complete job scheduling library. It leaves the writing of a Web interface to someone else, but for scheduling jobs it gets the job done. (Haha, that pun was irresistible)
The choice of Mongo vs Redis was intentional. Without configuration Redis doesn't guarantee persistence as well as Mongo. Since Redis is often used for non-critical data such as sessions I didn't want to enforce sacrificing performance of sessions for persistence.
So if you reboot the server, you just need to make sure that you call agenda.start() again. This will start the job processor which looks for jobs that have come due in the database and process them. agenda.every('3 minutes', 'job name') is a special case in which it will only schedule that job once (because if you think about it, otherwise every time you ran that line you'd get a new job... This makes it so you can define it in the same file as where you call agenda.start() and not end up defining new versions of those repeating jobs every time the file gets ran). Hope this makes sense/helps.
Sorry for the delay, highly recommend using backbone-rails [1]. Reading the docs for Backbone and then the source for the adapters in that gem was really helpful. Ryan Bates also does a screen cast on it, but it costs money [2]. Nonetheless, his pro-line of casts are great if you can swing the $10/mo.
I also think backbone looks great in CoffeeScript, and since rails prefers it anyway, I think it works out. Here's a good tutorial on that: [3]
We do similar things and you might find some inspiration or things you'd like to build into yours. PS. I also did mine for getting familiar with some new web techniques (Backbone + Rails in this case)
"Smashing the stack for fun and profit" is absolutely a great introduction to the classic buffer overflow attack. It is also the foundation on which tons of exploits are built on: http://insecure.org/stf/smashstack.html
Once you've read that, I highly recommend going through Stanford's CS 155 practice assignment on the subject. Unfortunately I really can't find the assignment anymore but perhaps a more thorough search of their archives would reveal it.
However, here is a blog which details the answers to all of the problems and includes the problem themselves. It explains why they work, and how to get to them. Very helpful if you are interested in looking at more advanced techniques: http://blogs.hulmahan.com.ph/archives/category/hack-101
That takes care of the basic C sploits. Beyond that, it really depends which level you want to attack at. You can attack at the stack level for almost all programs.
For web applications, you can go at a much higher level with stuff like SQL Injection, Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), and Session Hijacking.
Lastly, I highly recommend "Grey Hat Hacking, The Ethical Hacker's Handbook." This book does a fantastic job of giving you a taste of hacking at all levels. It covers OS attack possibilities, network level attacks, exploit generation and more. It also does a great job of introducing you to a lot of tools that help get the job done. From there, you'll at least be able to think of what you want to learn about next.
I appreciate the feedback! We are still playing with the idea of how viable this is as an actual business. For me this gave me an opportunity to escape from the more standard tasks of freelance development and a chance to implement all the new toys (MongoDB, Backbone, CoffeeScript, Bootstrap, etc.). That being said, I think there are some interesting ways that this could become quite profitable. If not, it's still a great way to put my name to something when applying to incubators on other ideas
One thing we are looking into is building a sort of roommate resume. We have data on how much you borrow from friends, how long you take to pay back, how often you do and don't do your chores, etc...
I find as I am transitioning out of college, I am about to move again to a new place and now I'll need to find new roommates. I personally would pay a fee to have access to good roommates to choose from, especially if its backed up by some sort of tangible history (badges, analytics, etc.)
There's also a lot of opportunity here to make a game out of something not fun. Game mechanics are perhaps a bit over done, but none the less, it could be fun to compete against roommates for the title of best roommate. Hell, we could even incorporate something where all the roommates take a pool ($10 each for example) and the roommate with the highest points at the end of the month gets it.
Thanks, it's mostly Twitter bootstrap based. We definitely think that this application gets way more useful as a house has more roommates.
The problem with letting you browse around before inviting is that all of the tasks require some other user. I am very open to the idea of doing something so that people can somehow get use to stay dedicated so they don't forget about us while they wait for their roommates to join up.
Any ideas? Maybe a little preview video or something?
Yeah, the facebook authentication is kind of a double edged sword. We want it because it will make it easy for users to invite their roommates, and more importantly, it allows us to have the concept of an "identity" to tie actions to. Going forward this could let us create a sort of roommate-resume tied to your identity.