|
Well I had a link in my favourites that led me there. But when I typed "java development kit" into Google just now, that was the top link. I don't know where you got your link, which someone in QA also got.
|
|
|
|
|
Yours was probably routed through a different part of India.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I tried to download jre last week to my 2008 server only to see tar.jz files for windows. Really? Are we lazy or just mad at the world?
I also found that link to the .exe installer the OP specified but when I double click it it after downloading does nothing so -- no Jira for my server, Fogbugz still.
I'll try harder next week.
modified 24-Sep-16 14:24pm.
|
|
|
|
|
So one thing I'd love to do more of is reading/studying clean code/software. I've been reading material by Steve McConnell and Uncle Bob, which are fantastic... But I'd like to see more examples of the principles actually in code. I tried searching for Uncle Bob' GitHub and found it, but it's rather limited.. And haven't even been able to find any code by Steve McConnell online.
Are there any other folks who are known for writing good code that you'd recommend I check out? I'm looking for actual source code... Because just roaming around the web everywhere, I've found all kinds of nasty stuff! Bonus points for C# but really, C++, and Java would be understandable as well.
|
|
|
|
|
Just my $0.02 but I think you can only get so far by looking at other people's code. Just like writing a book, the only way to do it well is by actually writing a lot. Do look at good code, but don't spend too long on it.
Another thing is there is no objectively "well written" software. When you go out into the industry (I'm assuming you still haven't or are new to it), you will come across all kinds of a-holes who find fault with every f-ing thing no matter how well it's written. I think there was someone who posted here about how the boss rejected his code because the others were too incompetent to understand it.
Of course this is no reason to write shoddy software, but it is better to adopt your style to the situation at hand, and to develop your own style irrespective of what others are doing. There is no reason to reinvent the wheel, but even less reason to not innovate just because something good enough is already available. From personal experience, I am less and less inclined to actually create anything because it is so easy to string together other people's code (employers seem to expect it too, given the tight deadlines and ridiculous budgets), and it has had a detrimental effect on my work quality.
|
|
|
|
|
Interesting, yet what you said makes sense about deadlines and stuff... Unfortunately the real world doesn't always allow for nicely-put-together stuff... In any profession really.
Well, I've been reading several good software engineering books lately and was just looking for more real-world examples besides the simplified stuff in the book. Surely someone must be able to write what they call "clean code", no?
If not, what exactly are most employers judging you on? If they don't really care about the code quality, then what are they looking for in the interview?
I've done a few small projects/freelance jobs but I have not yet formally worked for an employer.
|
|
|
|
|
TheOnlyRealTodd wrote: If not, what exactly are most employers judging you on? If they don't really care about the code quality, then what are they looking for in the interview?
Often enough the interviews have little to nothing to do with the actual work. Some were so creative when it came to avoiding standards that you ended up doing the opposite of what all experience or common sense would command.
In such a place it's very important to claim every (rare) success for yourself while pushing the blame for the (frequent) failures on somebody else, independently of what you worked on or not. Such places are like sinking ships, only that everybody will fight for the best positions, not for a seat in a lifeboat. If you end up in such a madhose, do yourself a favor and get out of there as fast as you can.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
What employers look for is varied, depending on a lot of things like the size of the organization or the management style
The other day I was talking to one of the HR guys (a most un-catbert like individual) and he said that what they mainly want to know in interviews is whether the candidate can use prior knowledge and experience to do his job
So say they want someone to maintain their ASP.NET website. The ideal candidate would already have several years experience in doing just that, but failing that (which is usually the case), they would try to get someone with at least some experience in some .NET technology. Hiring a Linux kernel developer is not going to be a good idea here.
Another thing is whether they will fit in with the team. Some rock star programmer is not going to cut it in a large corporate environment, they would rather go for someone with less ability who works well with the team than a super coder who is socially inept and pisses everyone off.
This would probably be less of an issue in startups, where they do want people who are super performers at the expense of social skills.
Code quality is something that they won't find out in interviews. Maybe they look at your github repo or something, but there aren't nearly enough people who even have one in the first place. Or maybe they throw out the duds during the first few weeks at work, not that I have seen it happen very often.
The cynic in me says that employers want people who work long hours for peanuts and not raise a stink about it, but I guess that would be a shortsighted policy.
|
|
|
|
|
California 90025 wrote: there is no objectively "well written" software
It's often easier to spot badly written software and there seems to be some consensus on what that is. Just last week I had to work with some SQL code that was written like SELECT somefields FROM table1, table2 WHERE table1.id = table2.table1_id. Now that's fine code... If you live in the 80's before proper joins were invented. I even found a where ... ( +) (it was Oracle) that I couldn't even read. Apparently the ( +) is an outer join from before outer joins were invented.
You may be thinking it was an old project and people didn't know better at the time, but actually that code was written two weeks ago 
Ask a million serious SQL developers what they think of this code and I think (hope) at least 99% would agree that it was actually bad code.
Now replace it with proper joins, ask those same developers again and now your developers will be squabbling about casing, indentation and even the order in which you write your where-clause 
|
|
|
|
|
California 90025 wrote: Another thing is there is no objectively "well written" software. When you go out into the industry (I'm assuming you still haven't or are new to it), you will come across all kinds of a-holes who find fault with every f-ing thing no matter how well it's written. I think there was someone who posted here about how the boss rejected his code because the others were too incompetent to understand it.
I've wondered about this, as someone who has not yet worked at a shop. I hear a lot about how there really isn't any ideal code and "as long as it works, it's fine" but at the same time, there are highly acclaimed books and articles that suggest that there is in fact a "right way" to write code, such as Code Complete by Steve McConnell, and that Clean Code book by Uncle Bob.
Ultimately, of course this is just their suggestions, but nonetheless, they seem to be well-accepted suggestions. Though, I believe every word you say about people picking apart your code no matter what, I may not have worked at a shop yet, but I've been working with people for a long time, lol.
|
|
|
|
|
California 90025 wrote: California 90025
I assume this means you're around WeHo? I'm in Studio City.
Jeremy Falcon
|
|
|
|
|
You'll often learn more from looking at poorly written code, because you're fixing it in your head, and coming up with new ideas -- so the worse the code, the better.
Is the windows 10 source code available?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You're a cruel man! 
I suspect that Win10 was actually pretty well written - the problem is that it's badly designed. It fits an "ivory tower" ideal rather than the real world, and that's where the problems start. Then patches get chucked in to make the ideal sort-of-work in the real world (despite the real world's strenuous objections) and that makes the situation worse.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Whoa!
Are you saying that the ribbon and baby blocks are "ideal world"?
Only smoke the wool from the black or white sheep, Griff. Leave the green ones be.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Nope, they're solidly Ivory Tower! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Writing "Clean Code" is a wide field. My point is, that is a design problem and has to do with software architecture. So reading some clean code wont help you anyway.
Maybe this book about clean code helps you developing such skills.
"Clean Code" isnt for itself but
- avoid bugs with sound and state of the art principles and
- mostly maintainability. (my main point, because I use code with 10+ years)
By that the coding speed increases and the cost of development are sinking. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
This may attract hoots of derision but actually a lot of the MS open-sourced code is quite high quality. Look at (for example) Entity Framework or Orleans on GitHub?
|
|
|
|
|
The problem with that is a lot of it is subjectivity. For instance...
var x = (y == 5) ? 0 : 1;
var x;
if(y == 5) {
x = 0;
} else {
x = 1;
}
var x;
if(y == 5)
{
x = 0;
}
else
{
x = 1;
}
var x;
if(y == 5)
x = 0;
else
x = 1;
And who's really right or wrong?
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: And who's really right or wrong?
COBOL's right, of course:
IF y = 5 THEN
x = 0
ELSE
x = 1
END-IF.
(Whatever you do, don't forget the fullstop)
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: COBOL
How DARE you mention that... that... THING here in the Lounge! To the Soapbox with you!
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Nothing wrong with COBOL
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
The third option is correct.
Jeremy Falcon wrote: And who's really right or wrong?
I am.
|
|
|
|
|
your first example is not the same as the others:-
?: is NOT if-then-else...
var x = (y == 0) ? 0 : z / y;
var x;
if (y == 0) x = 0; else x = z / y;
If it were easy then anybody could do it.
Wait, .... what!
|
|
|
|
|
I'm not sure if this is sarcasm or not. 
Jeremy Falcon
|
|
|
|
|
To me, studying what good code looks like and the best practices thereof has more value than looking at somebody else's code. I consider the reference article here[^] to be of more value than a bunch of code.
If you want to lose your mind, read the source for the stl libraries.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
