I feel like "web developer" is way too broad of a categorization.
That's part of the problem. Classically web developer meant the person was actually making the frontage to a website or application. But then php and things like cgi started diluting that word to mean someone who could do both.
At this point, if you can't design a good website as a programmer, you will never really be able to hold a job in that field unless your employer is intelligent and understands the difference between the two skillsets.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
admanbunionize your workplaceSeattle, WARegistered Userregular
I feel like "web developer" is way too broad of a categorization.
As a general job description it's not anymore broad than any others (including "Developer" which is my actual job title). The problem is that for some reason non-tech people see the word "web" and you immediately transform from a bespectacled nerd into an artsy looking hipster and their expectations change completely.
After millennia of heated debate, mercifully, at long last, we have an answer. Most developers prefer tabs to spaces.
Upon closer examination of the data, a trend emerges: Developers increasingly prefer spaces as they gain experience. Stack Overflow reputation correlates with a preference for spaces, too: users who have 10,000 rep or more prefer spaces to tabs at a ratio of 3 to 1.
My take: the spaces folk are older because of legacy advantages to spaces and also more opinionated, therefore having high stack rep.
(Us tabs folk are busy getting shit done at our jobs instead of posting on Stack. :razz:)
I'd argue that it's because, with experience, you're picking up different languages where the conventions start differing. In particular, C-like imperative languages prefer 4 spaces/tab and functional languages prefer 2 spaces/tab. I stuck to tabs until I had to begin moving between multiple languages that have different tabbing/indentation/formatting conventions. Now, I use spaces to adapt my code to whatever context I'm in.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
You want website functionality? That's a developer.
You want a website? That's a designer.
Web developer = php/js/sql/etc
Web designer = photoshop/images/HTML/CSS
Developer can help with the HTML part as needed for interfacing with functionality. They should never be asked to perform sweeping layout changes.
Designer shouldn't be tasked with interfacing with any of the developer's work other than making the site.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
As opposed to another one of those "har har I'm an embedded developer oh look because I'm on an embedded platform that gives me license to break all the rules because I'm a special embedded snowflake".
Breaking the rules? Nah son, stay as close to ISO and be as developer friendly as possible because that means I can look at cute dog pics in my downtime instead of troubleshooting code I've fucked trying to be obtuse and lazy.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
And yes, the times are the relationship. They're also related by user_id, but users have a 1..* relationship to both windows and messages.
Basically, devices could submit messages repeatedly, even when they are expected to only send one. Rather than have the application to tell them to knock it off, we actually want to capture this data. Thus, no relationship.
I have been tempted to give up and grab the nearest (by time) receiving_window record and pretending that's a valid FK, but that probably wouldn't help in the long run.
Maybe share the actual schema?
Now that I'm decompressed from the holiday flight home, I can share.
Okay, so the second query is about "show me user-days where there are messages outside the windows for that day"?
Start with the messages, would be easiest. You're looking for outliers, and they have a timestamp, so you can filter to just the ones you need to check fairly easily, either by one date or a range, all users or just an individual, etc.
cast(X as date) should be whatever appropriate for your language that gives you just the date part with no time.
select distinct M.user_id, cast(M.created_at as date)
from messages M
where cast(M.created_at as date) = $DateParam$ /* this is your main filtering clause */
and not exists (
select * from windows W
where M.user_id = W.user_id and M.created_at >= W.start_time and M.created_at < W.end_time
)
"Get all messages for that day, but only where they were outside the window (where not exists ...)"
You can also do it as a join but the exists subquery style is usually much more readable and nice to work with.
The distinct/cast in the main select will collapse it down to just the user-date pairs, if that is all you're interested in here.
Infidel on
0
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
edited April 2015
this is why im pretty happy with my current job/employer.
I am a UI Engineer and that means i am basically making nodejs apps and widgets. i dont have have to worry about html/css beyond using it for like an underscore template for a modal or whatever. They don't expect me to do design and in fact very much do not want me to do design as they have a seperate UX team that does all that.
thats also a thing i mention in every interview i ever do. I say that, yes i know photoshop enough to take a design and turn it into css/html, but i am no way a designer and should not be considered for it if thats what they want.
We're in a sort of intermediate position -- there's a UX team that does the design/paper prototyping/hallway tests/all that stuff, and provides us with "from Here to There is 20 pixels, or if you can't make it, make sure it's twice as wide as between Hither and Yon. This button is #123456 normally, #345678 hover, #567890 active" sort of specs. There's the folks that actually make icons with photoshop/illustrator/etc, and then there's us coders. We take the workflow design and turn it into javascript, and we take the sizing/colour specs and turn them into HTML/CSS.
On which note, boy is CSS ever awful if you want to do anything difficult. The basics, fine, that's all good, and the cascading style sheets part of it is fine. But the float/div/clear/positioning/box layout rules are all an awful lot of voodoo and I would rather go back to plain old GDI / .rc files an awful lot of the time, sheesh.
(not to mention we just got our translations back, and to nobody's surprise, most languages that aren't English take up more space than English, so a bunch of buttons suddenly don't contain their contents. Sometimes we we can just make them taller and rely on wordwrap, German and a couple of other languages tend to just GlueWordsTogetherIntoGiantWords so that there's nowhere for wordwrap to happen, and that's a real pain. I am very glad that arabic/hebrew/the other RtoL languages are "second tier" so we can pretend that doesn't exist for a little while longer; I RtoLified a UI a while ago and it was just super duper no fun, even when theoretically it should all work automatically once the browser knows what's up)
0
NogsCrap, crap, mega crap.Crap, crap, mega crap.Registered Userregular
Ecco is Procrastinating Before Getting Into Refactoring The Goose Out of Geese Code
This is what I am seeing (anonymised)
struct tBad
{
std::vector< double > a;
std::vector< double > b;
std::vector< double > c;
std::vector< double > d;
std::vector< double > e;
// actually has over 15 of these
};
As far as I can tell, the design has it so that a.size() == b.size() == c.size() == d.size() == e.size() at all times... but there is no need for that specific memory layout.
Just rolled my own CI setup for my Meteor app, pulls from Github develop branch to my dev server and is built and deployed and reloaded.
Clients get hot push of code as soon as the browser detects!
There are some dated tools and some all-in-one solutions that didn't fit my needs for this, maybe I'll have to do a writeup of how to put it together without all the bloat or lock-in of the main option out there.
Because fuck your objects, I have parallel arrays!
This kind of programming is very... Perl-like.
@ecco the dolphin did this dev work primarily with perl like... 5-10 years ago or something?
That's not even 5-10 years ago Perl. I wrote Perl full time from 2006-2011 and fiddling as a hobby before that. Perl has had objects (albeit clearly tacked on as an afterthought) since the mid-90s and OO is very much an accepted, encouraged way to write Perl. Most bad Perl you come across is because the developer was bad, not Perl. My experience with code like that in Perl is that it was old C programmers who decided (or were forced) to write stuff in Perl and didn't understand (or couldn't be bothered to learn) OO or how the language itself really worked.
Perl has plenty of issues, to be sure. Many of them from early versions where new features were added to make the problem go away, but those features are still entirely optional and off by default (things like use strict;). The others being Perl allows for super, super compact code, which can be great for that one off script, and then people (arguably falling into the bad programmer category) applying those same sensibilities of letting the magic just work to reduce dev time when they write larger, more complex stuff, resulting in a ton of uncomprehensible magic. That won't be parallel arrays, though, that'll be what appears to be a fully functioning web server written in 5 lines of line noise or whatever.
I'm sure the books are way too old for you to remember what they are, huh? I'd be curious just to see if they are super old, maybe were focusing on some specific thing, etc.
The courses I'll chalk up to being taught by some teacher that never actually learned Perl and just basically writes C using Perl syntax, because that's fully what I'd expect from nearly any college course touching Perl.
All the Perl I've worked with here has basically been C-like in the way it's used. The thing I've been working on is an in-house suite of Perl scripts, but has also been around for probably 15 years. They're just now working on getting OO as part of the common modules.
Yeah I'm 100% positive that's the case, and yeah, the book was old as shit. It was one of the first books I read about programming when I was a kid because my dad worked in the medical field and some system he was implementing needed perl to interface with it. I want to say it was version 3 or 4 of Perl.
I would probably guess it was written by COBOL/FORTRAN/MUMPS guys before C guys though, since they were getting away from the huge mainframes at that point. I don't think it was a legit publication you could find in a store. It think it was coil binded.
It was around 1993? I think I was 9 or so.
Reading perl books.
I was a weird kid.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Oh, that would make a ton of sense. Perl got OO in 1994.
Even then, you could use structs right?
Well, hashes/dictionaries, but yeah I'm sure pre-1994 Perl had them and they definitely would have worked. Perl's objects are actually just hashes with a bit more magic wrapped around them... you literally make a hash with your properties and then pass it into the bless() function to turn it into an object.
Oh, that would make a ton of sense. Perl got OO in 1994.
Even then, you could use structs right?
Well, hashes/dictionaries, but yeah I'm sure pre-1994 Perl had them and they definitely would have worked. Perl's objects are actually just hashes with a bit more magic wrapped around them... you literally make a hash with your properties and then pass it into the bless() function to turn it into an object.
Our father who art in binary.
bowen on
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Parallel data structures isn't Perl but a shitload of parallel data programmers went to Perl back in the day.
It is in the same boat as PHP, where there are solutions and good practices and books, but is haunted by the shit devs that have left an amazing legacy out there.
Posts
um. no.
The JS front-ends I work on are full applications that only go back to the server as an intermediary to the database. They do everything.
I get really fucking annoyed when clients expect me to do HTML/CSS because I'm a "web developer."
That's the part I'm talking about, sorry.
95% of the job interviews I've done with companies that do web technology they expect me to be a full time graphics designer too.
I can count the ones on a single hand that haven't because they understood the difference between a programmer and a designer.
That's part of the problem. Classically web developer meant the person was actually making the frontage to a website or application. But then php and things like cgi started diluting that word to mean someone who could do both.
At this point, if you can't design a good website as a programmer, you will never really be able to hold a job in that field unless your employer is intelligent and understands the difference between the two skillsets.
Gotcha.
As a general job description it's not anymore broad than any others (including "Developer" which is my actual job title). The problem is that for some reason non-tech people see the word "web" and you immediately transform from a bespectacled nerd into an artsy looking hipster and their expectations change completely.
I'd argue that it's because, with experience, you're picking up different languages where the conventions start differing. In particular, C-like imperative languages prefer 4 spaces/tab and functional languages prefer 2 spaces/tab. I stuck to tabs until I had to begin moving between multiple languages that have different tabbing/indentation/formatting conventions. Now, I use spaces to adapt my code to whatever context I'm in.
You want a website? That's a designer.
Web developer = php/js/sql/etc
Web designer = photoshop/images/HTML/CSS
Developer can help with the HTML part as needed for interfacing with functionality. They should never be asked to perform sweeping layout changes.
Designer shouldn't be tasked with interfacing with any of the developer's work other than making the site.
Damn, I feel old. I'm in the 40-50 age range and thus only 7.6% of the SO population.
Oo\ Ironsizide
At least with a junior dev, you can teach them.
As opposed to another one of those "har har I'm an embedded developer oh look because I'm on an embedded platform that gives me license to break all the rules because I'm a special embedded snowflake".
No
They're rules for a bloody good reason.
Now that I'm decompressed from the holiday flight home, I can share.
create_table "windows", force: true do |t| t.datetime "start", null: false t.datetime "finish", null: false t.integer "schedule_id" t.integer "user_id" t.datetime "created_at" t.datetime "updated_at" endcreate_table "messages", force: true do |t| t.integer "user_id" t.integer "direction" t.datetime "created_at" t.datetime "updated_at" endThere are no foreign keys, because rails is weird like that, but you can see the foo_id association fields on these tables.
I may end up coercing the (device) engineering team to add some kind of FK, but I'd like to get this working in the meantime.
Start with the messages, would be easiest. You're looking for outliers, and they have a timestamp, so you can filter to just the ones you need to check fairly easily, either by one date or a range, all users or just an individual, etc.
cast(X as date) should be whatever appropriate for your language that gives you just the date part with no time.
select distinct M.user_id, cast(M.created_at as date) from messages M where cast(M.created_at as date) = $DateParam$ /* this is your main filtering clause */ and not exists ( select * from windows W where M.user_id = W.user_id and M.created_at >= W.start_time and M.created_at < W.end_time )"Get all messages for that day, but only where they were outside the window (where not exists ...)"
You can also do it as a join but the exists subquery style is usually much more readable and nice to work with.
The distinct/cast in the main select will collapse it down to just the user-date pairs, if that is all you're interested in here.
I am a UI Engineer and that means i am basically making nodejs apps and widgets. i dont have have to worry about html/css beyond using it for like an underscore template for a modal or whatever. They don't expect me to do design and in fact very much do not want me to do design as they have a seperate UX team that does all that.
thats also a thing i mention in every interview i ever do. I say that, yes i know photoshop enough to take a design and turn it into css/html, but i am no way a designer and should not be considered for it if thats what they want.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
You're going to get the job, but we both know it's not going to lower your blood pressure any.
On which note, boy is CSS ever awful if you want to do anything difficult. The basics, fine, that's all good, and the cascading style sheets part of it is fine. But the float/div/clear/positioning/box layout rules are all an awful lot of voodoo and I would rather go back to plain old GDI / .rc files an awful lot of the time, sheesh.
(not to mention we just got our translations back, and to nobody's surprise, most languages that aren't English take up more space than English, so a bunch of buttons suddenly don't contain their contents. Sometimes we we can just make them taller and rely on wordwrap, German and a couple of other languages tend to just GlueWordsTogetherIntoGiantWords so that there's nowhere for wordwrap to happen, and that's a real pain. I am very glad that arabic/hebrew/the other RtoL languages are "second tier" so we can pretend that doesn't exist for a little while longer; I RtoLified a UI a while ago and it was just super duper no fun, even when theoretically it should all work automatically once the browser knows what's up)
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
This is what I am seeing (anonymised)
struct tBad { std::vector< double > a; std::vector< double > b; std::vector< double > c; std::vector< double > d; std::vector< double > e; // actually has over 15 of these };As far as I can tell, the design has it so that a.size() == b.size() == c.size() == d.size() == e.size() at all times... but there is no need for that specific memory layout.
LEVEL 1 FACEPALM
Why is this not:
struct tContents { double a, b, c, d, e; }; struct tRefactor { std::vector< tContents > data; };Especially because there is just copy and paste of a.resize( newSize ), b.resize( newSize ), c.resize( newSize ); etc.
LEVEL 2 FACEPALM
They're using std::vector<>::capacity(), not std::vector<>::size().
I don't even know why.
Especially because they mean size(), not capacity()!
Not with the access patterns that I'm seeing!
Hahahhaahahahaaaa*sob*
I bet that some of this came from copy paste code. Originally would have been std::vector< double >, and that worked.
So what do you do next when you want to add more fields?
Well, let's copy what works, and paste it in.
And now, this has over 15 vectors.
Double ewwwwwwwww teeee eeeffffffffffffff
Clients get hot push of code as soon as the browser detects!
There are some dated tools and some all-in-one solutions that didn't fit my needs for this, maybe I'll have to do a writeup of how to put it together without all the bloat or lock-in of the main option out there.
(It doesn't even let you use a secured database.)
This kind of programming is very... Perl-like.
@ecco the dolphin did this dev work primarily with perl like... 5-10 years ago or something?
That's not even 5-10 years ago Perl. I wrote Perl full time from 2006-2011 and fiddling as a hobby before that. Perl has had objects (albeit clearly tacked on as an afterthought) since the mid-90s and OO is very much an accepted, encouraged way to write Perl. Most bad Perl you come across is because the developer was bad, not Perl. My experience with code like that in Perl is that it was old C programmers who decided (or were forced) to write stuff in Perl and didn't understand (or couldn't be bothered to learn) OO or how the language itself really worked.
Perl has plenty of issues, to be sure. Many of them from early versions where new features were added to make the problem go away, but those features are still entirely optional and off by default (things like use strict;). The others being Perl allows for super, super compact code, which can be great for that one off script, and then people (arguably falling into the bad programmer category) applying those same sensibilities of letting the magic just work to reduce dev time when they write larger, more complex stuff, resulting in a ton of uncomprehensible magic. That won't be parallel arrays, though, that'll be what appears to be a fully functioning web server written in 5 lines of line noise or whatever.
The courses I'll chalk up to being taught by some teacher that never actually learned Perl and just basically writes C using Perl syntax, because that's fully what I'd expect from nearly any college course touching Perl.
I would probably guess it was written by COBOL/FORTRAN/MUMPS guys before C guys though, since they were getting away from the huge mainframes at that point. I don't think it was a legit publication you could find in a store. It think it was coil binded.
It was around 1993? I think I was 9 or so.
Reading perl books.
I was a weird kid.
Even then, you could use structs right?
Well, hashes/dictionaries, but yeah I'm sure pre-1994 Perl had them and they definitely would have worked. Perl's objects are actually just hashes with a bit more magic wrapped around them... you literally make a hash with your properties and then pass it into the bless() function to turn it into an object.
Our father who art in binary.
It is in the same boat as PHP, where there are solutions and good practices and books, but is haunted by the shit devs that have left an amazing legacy out there.
A 9 year old trying to understand programming is funny I guess, I never got much further than some simple stuff.
25 years later...