by Pasha Bitz, Product Manager
Just in time for the Halloween, Delver brings you this years hottest costumes!
By Guy Haimovitch, Product Manager
Imagine a world in which you get exactly what you want for your birthday. When working for Delver that world is our reality.
When HR first decided to treat every birthday boy or girl working at Delver with a little somethin’ somethin’ for their birthday, the process was a bit squeaky. The presents were very generic (store credits, etc) and non-personal and somewhat disappointing. Today we use Delver to “help our HR help us”.
3 weeks before my birthday comes up, I get the following reminder on Delver:
A week later, my friends (including our HR department employees) get the following reminder:
When HR gets this reminder they just choose the items from my wish-list that fit their budget and know they’ll get exactly what I want.
Since I still want a (partial) surprise, I just add A LOT of different items so I will not be sure of what I’m getting.
If you think this can work in the place you work at, send this article’s link to your HR dept and make a wish.
For more great features, visit Delver.com.
by Pasha Bitz, Product Manager
Delver is proud to have Dr. Dan Feldman give a guest lecture on the subject of Coresets and their applications in machine learning.
Coresets theory is a new and promising field in geometric algorithms which provides approximate solutions to large scale optimization problems in high dimensional vector spaces.
The lecture will be held on Thursday, October 21st 2010, from 17:00 until approximately 18:30, at the Delver Israel offices:
Akershtein building A, 3rd floor
9 Hamenofim St., Hertzliya Pituah
Registration is open and free, but required. Please RSVP to firstname.lastname@example.org
About Dan Feldman:
Dr. Dan Feldman is a post-doctoral researcher at Caltech, California. His fields of interests include Data mining, Geometric Optimization and Streaming Algorithms.
He received his Ph.D from Tel-Aviv University under the supervision of Prof. Amos Fiat and Prof. Micha Sharir.
The paradigm of coresets has recently emerged as a powerful tool for eﬃciently approximating various extent measures of a point set P. Using this paradigm, one quickly computes a small subset Q of P, called a coreset, that approximates the original set P and then solves the problem on Q using a relatively ineﬃcient algorithm. The solution for Q is then translated to an approximate solution to the original point set P. This paper describes the ways in which this paradigm has been successfully applied to various optimization and extent measure problems.
By Tomer Gabel, Application Engineer
A little while ago I posted a job opening for the application engineer position at Delver, and one of the replies caught my interest: “so it’s a DevOps position?” A Google search later and I was astounded to find what I tried to explain has since grown into a fully fledged industry trend.
I’ve learned to be mistrustful of such trends; in my experience they tend to inflate and deflate regularly, and if you try to keep abreast of all the proposed improvements to the development process you’re going to drown in overhead. Still, a critical percentage of these trends have a valid rationale driving them: unit testing, concurrency constructs, event-driven application servers, RESTful interfaces – all of these have very solid theoretical and/or practical reasoning and have had significant impact on the software development field. An additional commonality is: each took several years to gain acceptance in leading R&D teams, and several more to become ingrained methodology. The key word here is risk management, which is typically avoided or ignored altogether by the common developer.
Don’t get me wrong: I come from a purely R&D background, and have shared that trait for years. What started me on a different line of thinking was the distinct pleasure of being woken up, once too often, by some poor NOC operator in the middle of the night, and getting mad enough to do something about it. Like most R&D personnel I was largely oblivious to the pains of deployment, availability, scaling, production troubleshooting and customer support, and had to learn my lessons the hard way. I believe most R&D people aren’t more minded of the pains inherent in each of these domains because of the simplest of reasons: they’ve never been challenged to do so.
This is where “DevOps” comes in.
An application engineer (app engineer or “devops guy” if you will) has two primary objectives:
• Guide the R&D team in risk assessment. Having a software-savvy operations team member participating in design reviews is a huge boon to risk management; a better app engineer will want to participate in the design process itself, not necessarily designing the actual feature†, but even a quick overview of the proposed design is usually enough to provide operational feedback. This, without fail, results in a better design: clearer error-handling semantics, better monitoring and configuration facilities, high availability baked into the design, and induction into the deployment/administration toolchain concurrently with development efforts. This in turn leads to much better overall estimates and reduced failure rate.
• Keep the system up and running! This entails more than just observing the monitoring system (in my opinion, the less time you spend that way the less you are likely to have to, ad vitam aut culpam). The application engineer is in the relatively unique position of being both the consumer and producer of his or her own tools; this is where the wheat is separated from the chaff: a great app engineer will forever strive to improve and automate every nonfunctional aspect of the system, diligently working towards that asymptotic 100% uptime‡. DevOps personnel are the go-to people for getting systems off the ground; they’ll sketch the solution out, provide short- and long-term plans for deployment, monitoring and administration solutions both system-wide and component-specific. They’ll devise automatic tools to identify problems and anomalies, they’ll work ever-more-specific endpoints into their monitoring system, and they’ll be happy doing it because contrary to nearly any other position in the industry their interests and the business’s inherently converge.
Both DevOps and management would like nothing more than a clean, orderly universe in which systems do not fail, no data is ever lost and the system performs optimally on as little hardware as possible. Management’s business is budget and revenue; app engineers simply do not want to be woken up in the middle of the night.
Next up: Growing a DevOps organization, stay tuned!
† While not mandatory by any means, some design cycles can significantly benefit from an operational perspective; examples include static content management for websites; high availability for various system components; and any subsystem with external dependencies.
‡ A DevOps position is inherently multidisciplinary; for example, R&D background can significantly assist in troubleshooting. design reviews and in rolling your own tools. Strong system analysis skills, however, may be even more important, as they enable the two most important functions of the application engineer: spotting subtle holes in the design phase, and under-fire troubleshooting (which often requires the elusive ability to rapidly – but accurately – jump to conclusions).
by Pasha Bitz, Product Manager
You can now see profile info and content created by a Delver user in the new tabbed profile screen.
The redesigned screen shows: recent activity, personal info, catalogs, “help me choose” polls and friends.