The most amusing of these that I get is the "We're gonna cancel your facebook account if you don't click this link!" ones...
It's humorous because I don't have a FaceBook account.
The most amusing of these that I get is the "We're gonna cancel your facebook account if you don't click this link!" ones...
It's humorous because I don't have a FaceBook account.
I'm pretty much self-taught, and on-the-job learned a lot of what I know regarding computer programming and software engineering.
A couple of years back, though, I thought it might be beneficial to get a degree (since I don't have one).
Unless I'm mistaken, there are a few things that "the real world" teaches you that you can't (and usually don't) learn in a classroom.
Things like refactoring, design patterns, unit testing, and so forth. A lot of those things aren't learned in the "classroom" as far as I can tell.
Of course, I'm early in my school work, but so far I think my knowledge that I've gained on the job surpasses what I have learned in the classroom to this point.
But unfortunately, a lot of schools don't accept "work experience" for credit.
Here's another one from the same guy...the guy who's the architect, and is supposed to point these things out at design-time.
We put together some tables, and used the standard int type as the ID field. Well, our code is heavily reliant on data types matching up. So we write the C# with an int data type, as well, for this field.
So the architect, without telling us, changes the int field in the DB to a bigint, and chaos ensues. All kinds of stuff breaks.
So then we lose a day or two "fixing" code that wasn't broken if he would have left things alone.
Seems they were worried about ID numbers or some such, and were afraid they'd run out. Or something.
Yeah?
When I started we only had 1's and 0's...and sometimes we didn't even have that!
;-)
Not literally...but one did cause us to lose almost a day of work...
He was one of those who did software and DB coding...
And I guess he was trying to move data or something, because he assumed his write to a temp table worked. But it didn't, and so it wiped out a LOT of data we were using in our development environment. It broke all kinds of stuff, because now keys were off, and we had records that wouldn't match...
Oh, we still would have had to fix it, but it was in the middle of our iteration, and we had to stop what we were doing, and almost missed a successful iteration because of it. They frown upon us "missing" iterations where I work. They want us "code complete" by day 7, so we can give the QA team 3 days or so (of a 10 day iteration) to do their jobs correctly.
They already had a "convention" in place for most (all?) of their tables for int to be used -- we were basically following convention.
One of the principal developers wrote most of a "framework" to use. This framework somewhat simulates Entity Framework, except that we have to also inherit RegularFrameworkClass or BigFrameworkClass, based on the int (or bigint) declaration. Most of the classes we used inherited RegularFrameworkClass, but after this Architect made the change, we had to go back and change RegularFrameworkClass to BigFrameworkClass.
I don't know if they're afraid they'd run out. They wanted the ID to maybe start at a specific number, I guess? But still, that 2 billion plus would allow them 6 records per second, for about a decade before they needed to change anything.
They didn't tell us (or coordinate with us) to make the change. They just did it, and didn't tell us.
I'm a believer that one of the hallmarks of a good software engineer is the ability and willingness to ask other software engineers for advice, and to be smart about of whom that advice is asked (is that right??). Especially those more experienced software engineers.
Anyway, I have what I believe is a pretty good idea for a mobile app. There's probably tons of this kind of app out there already, so one more won't hurt. ;-)
Anyway, I know that for the data I want to use AES encryption. I just don't know if I want to store the data on the user's device, in the cloud, or both.
It's a simple, straightforward app.
I don't really even know if I should do it...I mean, it's one of those "practical" ones...and it seems like more people these days are into "entertainment" or "informational" apps, instead of "practical" ones. But then again, what do I know?
Anyway, some opinions on where to store the data would be appreciated. Also, what mobile devices should I target? I'm primarily a C# guy, but I'm teaching myself some Java. I could probably use Xamarin to do a C# app, or I could do a Web Service with a JavaScript library front-end, so I have some options.
As I said, though, I'm just getting started with this. I haven't seen the entire curriculum. As far as I know, the things I've mentioned could indeed be taught later.
I've heard that Xamarin supports all those formats. I'm much more familiar with C#, but I'm not averse to learning Java (which I already am) or ObjectiveC.
Although, with things like PhoneGap, it's possible (or so I've heard) to basically write a "back end" (i.e. a web service), and call that from some JavaScript on the mobile device, and have things work that way.
There could be connectivity problems there, though...
I don't have the code, so unfortunately I don't recall what it was supposed to do...
They already had a "convention" in place for most (all?) of their tables for int to be used -- we were basically following convention.
One of the principal developers wrote most of a "framework" to use. This framework somewhat simulates Entity Framework, except that we have to also inherit RegularFrameworkClass or BigFrameworkClass, based on the int (or bigint) declaration. Most of the classes we used inherited RegularFrameworkClass, but after this Architect made the change, we had to go back and change RegularFrameworkClass to BigFrameworkClass.
I don't know if they're afraid they'd run out. They wanted the ID to maybe start at a specific number, I guess? But still, that 2 billion plus would allow them 6 records per second, for about a decade before they needed to change anything.
They didn't tell us (or coordinate with us) to make the change. They just did it, and didn't tell us.
Oh, we still would have had to fix it, but it was in the middle of our iteration, and we had to stop what we were doing, and almost missed a successful iteration because of it. They frown upon us "missing" iterations where I work. They want us "code complete" by day 7, so we can give the QA team 3 days or so (of a 10 day iteration) to do their jobs correctly.
Oh, this was DEV data, so I don't think he was too concerned. We were, though, as we us Agile and we lost a couple of days "fixing" code that didn't initially need to be fixed.
Here's another one from the same guy...the guy who's the architect, and is supposed to point these things out at design-time.
We put together some tables, and used the standard int type as the ID field. Well, our code is heavily reliant on data types matching up. So we write the C# with an int data type, as well, for this field.
So the architect, without telling us, changes the int field in the DB to a bigint, and chaos ensues. All kinds of stuff breaks.
So then we lose a day or two "fixing" code that wasn't broken if he would have left things alone.
Seems they were worried about ID numbers or some such, and were afraid they'd run out. Or something.
Yeah, he didn't put checks in. He just wrote the stored procedure, ran it, and hoped for the best, I guess. Because IIRC what happened is that his code tried to create a temp table, but didn't actually error check, and then truncated (or dropped, I don't recall) the table with the data in it...
Ok, several years back, I worked for a company that did a full-blown web app in Classic ASP, tied to SQL Server.
It was done by the "offshore" team.
My "team" (if you want to call us that) was to maintain it and help with installs.
The issue is, we noticed that on "fresh" installations, the code would break.
We tracked it down to 1 line. We had to comment out that one line, run the code, and then un-comment the code to get the app to work.
Conversely, my "team" (which consisted of me and basically two graphic designers) built a full-blown Classic ASP app with a SQL Server backend from the ground up (using Waterfall!), and we didn't have that issue.