| Editor: | Gordon van Gelder |
| Issue: | Volume 121, No. 1 & 2 |
| ISSN: | 1095-8258 |
| Pages: | 258 |
You keep using that word. I do not think it means what you think it means. -Inigo MontoyaHaving worked in full-time management positions for some years now, I am increasingly convinced that management is widely misunderstood as a role, as a discipline and as a field, and that this makes a lot of lives more difficult and stressful than necessary. It is the subject of much speculation and misbelief, and I ve chosen a few of my favorite examples to deconstruct here. Misbelief #1: management is what managers do I ve noticed a trend among a certain class of companies, whose employees will tell anyone who will listen that there is no management in their organization, they never plan to have any, and neither should you. I think these statements are respectively a lie, a na ve belief, and a piece of bad advice. Usually, these companies are just a few years old and relatively small, most of the people in the company have been there for less than a year, and the speaker is trying to persuade us what a unique and innovative company they work for because nobody there is a manager . They invariably have not read The Tyranny of Structurelessness. Management is the practice of enabling people to effectively cooperate. A manager is someone whose job is to do that. It s that simple. It usually involves tasks such as sharing information, agreeing on a course of action, dividing up work, and figuring out what to do when there s a problem. They re things that every team needs to do, whether anyone is designated a manager or not. Teams can function without managers, but they can t function properly without management. Someone (or everyone) has to do the work to make cooperation possible. Modern management is a specialized discipline, which draws on a broad range of skills in communication, psychology, empathy, problem-solving, leadership, and more. These skills aren t unique to managers, but it often makes sense to designate certain people to do more of the management work, on behalf of the team. By devoting more of their time and attention to it, they free other members of the team to focus on other tasks. They can act as a coordinator to help the team stay in sync, and by focusing on this job, they may be able to do a better job of it, and acquire a higher level of skill through practice and study. But it remains an inherently collaborative practice. Misbelief #2: management is about telling people what to do There are many different varieties of management, each of which is oriented toward a particular type of team or organization. Factories are managed differently from design studios, large companies are managed differently from small companies, and every team has its own distinct management style which arises from the unique group of people involved. Some managers are specialists in a particular type of management, while others are more generalists. The telling people what to do style of management is called command and control . It s characterized by authority, hierarchy, and strict adherence to protocol. It s widely employed by military organizations, and by the managers we see in television and film. It has some advantages and disadvantages, which I won t discuss here. My point is that it is just one example, but this example is used to represent the general concept of management. Self-organization, where no one in particular is responsible for group decisions, is another, quite different, style of management. Small, self-organizing teams are capable of amazing feats of productivity. They re less difficult to manage because they re comparatively simple, and so simple tools and techniques work well. Everyone can be fully aware of what everyone else is doing, and new information propagates quickly throughout the team. But as the team or organization grows, it will often outgrow this way of working, and needs to adapt. There is no single management approach which works universally well. Misbelief #3: management is a promotion You know the story. When an employee is successful within their area of expertise, someone will eventually offer them a management role as a reward for their good work. This is utter nonsense. Management is not a promotion: it s a career change. It means starting over as a beginner in a new discipline and learning from the ground up. Domain expertise is important, as a manager needs to understand the work of the other people on their team, but it is no longer paramount. The team, the human system, becomes their focus. When organizations fail to provide career advancement within a discipline, people may turn to management as the only way to get promoted , only to discover that they are completely unprepared for this new field, and often their new job when they realize what they ve gotten into. If someone were promoted from a position as a financial analyst to a new job as a biochemist with no training or expertise, we would probably find this bizarre. But this is analogous to what happens to new managers all the time, and has become almost standard practice in many organizations and industries. So what? Management is misunderstood. So are science, engineering, and many other fields. What does it matter?
People leave managers not companies in the end, turnover is mostly a manager issue, - Marcus Buckingham & Curt Coffman, First, Break All the RulesThis mythology leads to massive organizational dysfunction, making it harder for everyone to do their jobs. It virtually guarantees incompetent management, which is a scourge on anyone who is exposed to it. It ruins days, weeks, jobs and careers. It leads talented people to leave companies, and it drives them out of their chosen professions. I recommend that we stop denigrating and ignoring management, and start doing a better job of it.
Weblate 1.8 has been released today. It comes with lot of improvements, especially in registration process where you can now use many third party services.
Full list of changes for 1.8:
demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery.
Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others.
If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you.
Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far!
Filed under: English SUSE Weblate 2 comments Flattr this!
The following post is a verbatim copy of my message to the debian-devel
list.
While botch produces loads of valuable data to help maintainers modifying
the right source packages with build profiles and thus make Debian
bootstrappable, it has so far failed at producing this data in a format which
is:
| Series: | Celaeno #2 |
| Publisher: | Bold Strokes |
| Copyright: | 2004 |
| Printing: | March 2005 |
| ISBN: | 1-60282-349-9 |
| Format: | Kindle |
| Pages: | 320 |
> a = array(range(-1000000,1000001)) * 0.000001 > min(a), max(a), numpy.sum(a), math.fsum(a) (-1.0, 1.0, -2.3807511517759394e-11, 0.0)
> b = a + 1e15 > numpy.var(a), numpy.var(b) (0.33333366666666647, 0.33594164452917774) > mean(a**2)-mean(a)**2, mean(b**2)-mean(b)**2 (0.33333366666666647, -21532835718365184.0)(as you can see, numpy.var does not use the naive single-pass formula; probably they use the classic straight forward two-pass approach)
> import timeit > for f in ["sum(a)", "math.fsum(a)"]: > print timeit.timeit(f, setup="import math; a=range(0,1000)") 30.6121790409 202.994441986So unless we need that extra precision (e.g. because we have messy data with outliers of large magnitude) we might prefer the simpler approach which is roughly 3-6x faster (at least as long as pure CPU performance is concerned. Once I/O gets into play, the difference might just disappear altogether). Which is probably why all but the fsum function show the same inaccuracy: performance. In particular, as in 99% of situations the problems won't arise.
Today I'm recuperating, and almost back to full health.
Unfortunately I made the mistake of online-shopping, oops.
Good job I stopped myself from registaring all the domains, but I did get two that I liked: spare.io & edinburgh.io.
I've updated my database to record them, but I wonder what do other people use to remind them about expiration dates of domains, SSL-certificates, & etc?
I googled and didn't find a definitive free/paid service, but it seems like something lots of people need to be reminded about..
Maybe people just rely on registrars sending strident emails. (Of course the redemption period for domains make it reasonably safe to forget for a day or two, until your customers complain and your emails start to bounce..)
In a comment to yesterday s post on why your Puppet module
sucks, Warren asks
what can be done about the problem of multiple modules needing to include
the same package (gcc being the most common example I m yet to come
across).
As I stated
previously, there
is no sane, standardised way for multiple independent modules to cooperate
to ensure that certain packages are installed for their cooperative use. If
it wasn t already obvious, I consider this to be a significant failing in
Puppet, and one which essentially renders any attempt at public, wide-scale
reuse of Puppet modules impossible. Software packages are such a
fundamental part of system management today that it is rare for a module not
to want to interact with them in some way.
Without strong leadership from Puppet Labs, or someone core to the project
who s willing to be very noisy and obnoxious on the subject, the issue is
fundamentally unsolveable, because it requires either deep (and
non-backwards-compatible) changes to how Puppet works at a core level, or
it needs cooperation from everyone who writes Puppet modules for public
consumption (to use a single, coordinated approach to common packages).
The approaches that I ve seen people advocate using, or that I ve considered
myself, roughly fall into the following camps.
package resources you
end up creating will still conflict with other modules package resources.
Anyone who suggests this can be permanently ignored, as they don t
understand the problem being solved.
defined() function everywhere
By wrapping all your package resources in if !defined(Package["foo"])
blocks, you can at least stop your module from causing explosions. What
it doesn t do is make sure that the various definitions of the package
resource are congruent (imagine if one was package "gcc": ensure =>
absent ). In order to safely avoid explosion, everyone would
have to follow this approach, which (in the worst case) reduces the problem
to the globally common module of classes.
However, it s the least-worst approach I can practically consider. At least
your module won t be the cause of explosions, and realistically no
module s going to ask for gcc to be removed (or, if they are, you ll
quickly find them and kill them).
I ve seen calls from Puppet core dev team members to deprecate and remove
the defined() function entirely. Given the complete lack of alternatives,
this is a disturbing illustration of just how out of touch they are from the
unfortunate realities of practical Puppetry.
singleton_packages
This module is a valiant attempt to work around the problem, but practically
speaking is no better than using defined() because again, if a module
that isn t using singleton_packages specifies package "gcc": ensure
=> absent , you re going to end up with assplosion. The mandatory
dependency on hiera doesn t win me over, either (I m a hiera-skeptic, for
reasons which I might go into some other time).
package resources, using our module of common
classes where appropriate, or refactor modules to separate concerns
appropriately.
If you re wondering why we don t have all of these 158 modules available
publically, well, we have a few of them up, but
yes, the vast majority of them aren t publically available. Some of them
suck mightily,
while many others are just too intertwined with other modules to be able to
use on their own, and we don t want to release crap code there s far too
much of that out there already.
In a comment to yesterday s post on why your Puppet module
sucks, Warren asks
what can be done about the problem of multiple modules needing to include
the same package (gcc being the most common example I m yet to come
across).
As I stated
previously, there
is no sane, standardised way for multiple independent modules to cooperate
to ensure that certain packages are installed for their cooperative use. If
it wasn t already obvious, I consider this to be a significant failing in
Puppet, and one which essentially renders any attempt at public, wide-scale
reuse of Puppet modules impossible. Software packages are such a
fundamental part of system management today that it is rare for a module not
to want to interact with them in some way.
Without strong leadership from Puppet Labs, or someone core to the project
who s willing to be very noisy and obnoxious on the subject, the issue is
fundamentally unsolveable, because it requires either deep (and
non-backwards-compatible) changes to how Puppet works at a core level, or
it needs cooperation from everyone who writes Puppet modules for public
consumption (to use a single, coordinated approach to common packages).
The approaches that I ve seen people advocate using, or that I ve considered
myself, roughly fall into the following camps.
package resources you
end up creating will still conflict with other modules package resources.
Anyone who suggests this can be permanently ignored, as they don t
understand the problem being solved.
defined() function everywhere
By wrapping all your package resources in if !defined(Package["foo"])
blocks, you can at least stop your module from causing explosions. What
it doesn t do is make sure that the various definitions of the package
resource are congruent (imagine if one was package "gcc": ensure =>
absent ). In order to safely avoid explosion, everyone would
have to follow this approach, which (in the worst case) reduces the problem
to the globally common module of classes.
However, it s the least-worst approach I can practically consider. At least
your module won t be the cause of explosions, and realistically no
module s going to ask for gcc to be removed (or, if they are, you ll
quickly find them and kill them).
I ve seen calls from Puppet core dev team members to deprecate and remove
the defined() function entirely. Given the complete lack of alternatives,
this is a disturbing illustration of just how out of touch they are from the
unfortunate realities of practical Puppetry.
singleton_packages
This module is a valiant attempt to work around the problem, but practically
speaking is no better than using defined() because again, if a module
that isn t using singleton_packages specifies package "gcc": ensure
=> absent , you re going to end up with assplosion. The mandatory
dependency on hiera doesn t win me over, either (I m a hiera-skeptic, for
reasons which I might go into some other time).
package resources, using our module of common
classes where appropriate, or refactor modules to separate concerns
appropriately.
If you re wondering why we don t have all of these 158 modules available
publically, well, we have a few of them up, but
yes, the vast majority of them aren t publically available. Some of them
suck mightily,
while many others are just too intertwined with other modules to be able to
use on their own, and we don t want to release crap code there s far too
much of that out there already.
A new maintenance release 0.10.6 of
Rcpp is now
on the CRAN network for
GNU R;
binaries for Debian have been uploaded
as well.
This version ties up a number of smaller loose ends, but also adds a few new
things, particularly John's new exposeClass. Details are as
usual in the NEWS extract below, and also
in the ChangeLog file in the package and on the
Rcpp Changelog page.
Changes in Rcpp version 0.10.6 (2013-10-27)Thanks to CRANberries, you can also look at a diff to the previous release 0.10.5. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page
- Changes in Rcpp API:
- The function
exposeClasstakes a description of the constructors, fields and methods to be exposed from a C++ class, and writes C++ and R files in the package. Inherited classes can be dealt with, but require data type information. This approach avoids hand-coding module files.- Two missing
is<>()templates forCharacterVectorandCharacterMatrixhave been added, and some tests foris_na()andis_finite()have been corrected thanks to Thomas Tse.- Changes in R code:
- Export linking helper function
LdFlagsas well asRcppLdFlags.- Function
Rcpp.package.skeleton()no longer passes anamespaceargument on topackage.skeleton()- Changes in R setup:
- Raise requirement for R itself to be version 3.0.0 or later as needed by the vignette processing
- Changes in Rcpp attributes:
sourceCppnow correctly binds to Rtools 3.0 and 3.1
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Some catchup blogging: Kurt Elling was
back in town on October 19, and not just in Chicago but quite literally in our little 'burb
as the headliner for this season's concerts at Domiminican University.
They had done us the favour of inviting
Dianne Reeves
back in March 2009,
but this was clearly going to be a real treat. And I managed to snatch four front row (!!)
tickets as soon as I heard about it, and the show once again didn't disappoint.
Elling was as usual accompanied by his long-time collaborator Laurence Hobgood on piano,
as well as local heros Clark Sommers on bass and
John McLean on guitar. This time,
Quincy Davies was on
drums. And this band is realiably excellent, as is Elling in any live setting.
The set was dominated by pieces from his most recent record
and augmented by a few other standout pieces. There is a pretty rich set of
live music by Elling on YouTube, see for example
On Broadway (which
was part of the set in a wonderfully fast and funked-up variant),
Golden Lady (from
the previous album, and also played live this time) or for example this wonderful version of
You Send Me (also
part of the concert).
I snatched a photo or two (while at least turning my flash off, unlike the
weird gal to my left, but I digress) and
posted one on Google+.
Kurt Elling will be back in Chicago at
the Green Mill in early
January. Expect to me there, and I hope to see you too!
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
So, basically this didn't work right out of the box. Fortunately the GPGSuite support guys replied quick and solved this problem. The version they released yesterday did fix that problem, but I needed to add the following line to my ~/,gnupg/gpg-agent.conf, which didn't exist before too:
no-use-standard-socket
With that line everything works like a charme under OSX with Mail.app using my GPG keys on my Debian box.
| Publisher: | John Wiley & Sons |
| Copyright: | 1996 |
| ISBN: | 0-471-11709-9 |
| Format: | Trade paperback |
| Pages: | 621 |
This post is just a bunch of random notes, but I think that things are going
well, this time.
coursera-dl has a new home:
a github organization of its own!
ffmpeg -i audio.m4a -i video.mp4 -vcodec copy -acodec copy combined.mp4
If you prefer having a Matroska container instead of an mp4 container
(which, BTW, results in smaller muxing overhead), then you can use the
command line:
mkvmerge -o combined.mkv audio.m4a video.mp4
Oh, those m4a and mp4 extensions are a new addition that
I just sent upstream (in the past, both would have been named with an
extension of mp4).
As, an aside, I like formats 135 for video and 140 for audio, for the
reasons that I mentioned in a comments to issue 1612:
Otherwise, to download 480p videos (which I do for lectures and so on with other projects of mine, like edx-dl) I have to call youtube-dl twice: once for format 135 and another for format 140, since the oldWhile this is unfortunate for some, this is a good thing for others: I once had a blind user offormat 35 files are much smaller than the lower resolution 360p files (due to the former being encoded in High profile vs. the latter being encoded in Constrained Baseline profile).
youtube-dl asking me if he could avoid downloading the
whole video just to extract the audio, so that he save on bandwidth. Well,
now this is possible.
Expect a new version of youtube-dl to be uploaded soon to Debian unstable.
Next.