>> Specifically, if you have a team that doesn't communicate effectively on a daily basis,
I concur. My people don't communicate very well and have no real team spirit. The stand up meeting helps to alleaviate that.
Of course, people who "don't communicate" and "have no real team spirit" are not fit for Agile and stuff, but that's another story :-) In my case, Agile, having frequent deadlines and frequent stand up meeting, helps me a lot to maintain a soft pressure on people. I don't like that (I'd prefer a team of super motivated people), but that's the best I can do. Having a more formal method like RUP wouldn't help because the analysis/coding cycles are too long. Having a kanban could help a bit, as Agile with such a team feels a bit artificial.
If you need unicode (i.e. your app will take more langauges than english and spend a lot of time on that (hint! GUI hint!), the 3 is the way to go. Unicode support is so much better...
For the rest, it depends on the libraries you need...
I have a fairly large code base (80K LOC). When the size grows, lack of typing can become a problem. 95% percent of the time, the code is explicit enough. However, when you end up with meta code, then it can become really difficult to track the types down in the n-th level of recursion...
Python2 to 3 migration is not easy. There are tools but the problem is that they don't see everything and therefore, you end up with 95% of your code converted. Then it's up to you to figure out the last 5%, which is an order of magnitude harder that the first 95%... So I ended up having a fairly long transition of migrating Python2 code to Python2+3 code.
For bothe these issues, the common discourse is : have proper test coverage. But well, we live in a real world, and maintaining a code coverage strong enough to allevaite the problems (around 90%) is just very hard. If you're coding alone, that may be just too much (my case). In a team setting, with money to spend, that may be possible, but you'd need a very disciplined team.
But anyway, AFAIC, working with Python is just super productive (I compare to Java). It also feels much more battle tested than, say, Ruby.
For me python is not a scripting language but a "glue" language set in the middle of a huge libraries ecosystem.
Now, I didn't do XA transaction stuff, high performance stuff, etc. For me it's more alike a well done Visual Basic : you can achieve a lot very quickly. Contrary to VB, the language and its ecosystem are really clean.
Interestingly, here in Belgium, the press often states that Google pay his taxes as requested by the law. And that Google have some very expert accountant who read the law in suach a way that those taxes are close to zero.
I'm afraid Google doesn't pay his taxes like we, the tax payers, think it should...
Of course, that's totally proof-less, but well, I've heard that quite often (cf. intérêts notionnels)...
I concur. When hiring with these kinds of small problems, you actually see a lot. First, in my case, it sorts programmers from not-programmers (it's in the 50% ballpark). Then with a problem a bit harder, it helps sort "programmer-in-the-guts" from "programmer-for-a-job". At the end, I've removed 90% of the candidates and I'm left with average to very good programmers.
Moreover, leaving people to do these little tests in the team and proposing them to ask questions whenever they want, plus asking them to explain their solutions helps a lot in seeing the social skill I need (communication, openness...)
Of course, it's not 100% safe, but I'd say it's a good heuristic :-)
That's very vicious PR to me. By acknowledging some guys thre were hacked too, they implicitely say that : "we're in the same boat, anthema and their customers, we'll fight together". Which, at least for me, is completely wrong. They fucekd up and they put the customers in the siht.
So I cook to think about something else. Washing the dishes without dishwasher is also a moment where I let my mind wander.
Definitely not some time lost (to be honest I don't enjoy washing the dishes as much as cooking, of course, but I feel that connecting my brain on something "easy" is rahter good for me, else I'd jump on my computer right after eating...)
I've looked at the zommable picture. When I zoomed to the maximum, I saw a lot of noise in the picture (and a arather regular one). Does it mean that although the resolution is pretty impressive, the noise make it less "useful" ? Just asking, I've 0 knowledge in this area.
Second question, just out of curiosity, would it be possible to look at closer objects like Mars or the moon ? We'd have a pretty good image too ?
If I can judge from my child and his friends, I can tell you the angry birs brand is just massively popular and that the lack of story is absolutely irrelevant to them (they just care about levels, birds' powers, things they win, etc.) The story, bah, what for ?
First, instead of providing tools, one could help people to develop taste. Many accept overcooked chicken or fish because they just catch the spices flavours. They can't judge what a well cooked dish is. Dry chicken is an abomination...
2/ The thickness of a salmon filet is everything but regular. So cooking it correctly involves a bit more than temperature handling
3/ As said, you don't cook "a steak", you cook "this steak". That's the thing. Cooking a good steak involves so many thing : quality of the steak (forget about supermarket), quality and handling of the fat (Gordon Ramsay once made a very good explanation on how to use butter on youtube), make sure the steak rest enough time off the heat before serving, cook for steak's colour first (so it is beautiful) and then cook for bloody/well done/cooked. Cook long and not short. Don't use a fork to manipulate the steak. Don't turn the steak upside down to often. With an autoamted pan you may sure cook a steak but you won't know why you did it right...
4/ If your problem is overcooking or undercooking a steak, learn to touch the steak. Hard means overcooked, soft means undercooked. With a bit of practice you'll be able to make good steaks, not 3 star michelin ones, but good ones.
5/ For steaks (not fish) you can buy cast iron skillets. These are super cheap (15 euros here !)and they live forever. But you have to learn to master/clean/season them (that's your old grand ma stuff, but knowledge is lost so it's pretty hard)
6/ The salmon on the web site looks super over cooked to me (it s top side is super borw and just below it's all white)
7/ said before : a fryin pan that doesn't go to the oven is useless. Countless times where I fry a piece of meat and finishes it in the oven where I can get the temperature righ everywhere.
8/ will the pan stand the "deglaçage" ? That's when you throw a cold liquid in the pan to grab all the softly burned piece of meat/fat. that's super important to making sauces.
9/ Will it stand the dish washer ?
10/ Where's the fun ? I mean, if you buy this because you can't find the time necessary to learn to cook, and thus, learn to appreciate good cooking, what's the point ? Do yourself a favour don't buy the pan, look for a good restaurant (and at the price of the pan you certainly can find a good one) and ask the chef to prepare a good steak for you. You'll learn something.
Not to sound smart ass but I got that in 1996 when I was fortunate enough to have a course on Scheme by D. Ribbens here at Liege University in Belgium. He showed us how to build that very interpreter and how powerful it was (he used to say : forget about algorithms or OOP, here's the truly powerful stuff :-) ). Since then I contemplate the slow evolution of languages, leaning to functional programming (although Scheme is not FP, that's for sure).
That said, what could be taught to a young student today that would provide the same kind of enlightenment I had with those few pages of list(p) ?
I concur. PySide makes developement/prototyping really efficient : the code is easy to read, no build system to maintain, no heavy tools to run, portability makes life so much better, you can freeze applications => deployment is super easy (well provided you don't have to copy the file on every PC's of the customer :); can't beat the web for that). And plus, Qt is very old and thus mature. It may not be as fun as the web development (which I admit is funnier, at least for the GUI part) but it provides a solid, predictible framework... Now I admit, I didn't play with JQuery which looks very solid too...
is it me or the algorithm suggested at the end degenerates if the rectangles are organized as the steps of a stair and each of them extends to the rightmost position ? In that case it degenerates because the heap manipulation degenerates...
We, as a company, have no fucking core values.
At the beginning there were a few smart ass, business savy dudes with an idea they thought interesting to make.
So they started our company. They needed some additional forces to achieve their goal so we hired you !
Now, we have a mutual need for stability : we want to keep your talent inside, and you most probably want stability for your job (since you're just a non-entrepreneur guy)
To satisfy that need, the company looks closely at how to make you happy. So the company creates a few illusions :
- illusions of scarcity of money (we could pay you more but well, your market value blablabla)
- illusions of culture (whao, we work together 'cos we thing alike ! except well, no, we look for maximizing profit, you look at saving your salary)
- illusions of evolution (you will grow with us, except that well, all the benefits will be for the top mangement :-), unless you becom one of the founder, which implies taking a huge financial risk (rememeber ? you're an employee, so you won't make enough money to join the company's capital :-))
However, given the fact that things have worked this way for centuries, we both acknowledge the situation and think both of us will find a pocket of happiness in it.
So let met tell you once more : We, as a company, have f*cking values, pal, that's just an illusion we create because without that you'd thing that we're just a normal company (and our little ego doesn't want that :))
Interstingly they talk about the "change palette in the middle of the screen" tricks that we used in Imphobia. The precision timing was certainly tricky, especially when playing a MOD-file while drawing ! Ahhh memories...
I concur. My people don't communicate very well and have no real team spirit. The stand up meeting helps to alleaviate that.
Of course, people who "don't communicate" and "have no real team spirit" are not fit for Agile and stuff, but that's another story :-) In my case, Agile, having frequent deadlines and frequent stand up meeting, helps me a lot to maintain a soft pressure on people. I don't like that (I'd prefer a team of super motivated people), but that's the best I can do. Having a more formal method like RUP wouldn't help because the analysis/coding cycles are too long. Having a kanban could help a bit, as Agile with such a team feels a bit artificial.