My girlfriend's company cut pay by 5% across the board. Ironically, this actually INCREASED her paycheck, as it bumped her into a lower tax bracket.
Hmmm... what country are you in? In every country I've ever lived in, the tax brackets are staged so that "up to x" you pay y%, and only for the amount OVER x do you pay z%... this ensures that such a thing could never happen (getting a "payrise" and ending up with less sounds a little crazy)
For IT people, places like facebook, and myspace are the place to go, since their careers are still in the entry-level phase.
You have an odd definition of "IT people"... I've been working in "IT" for nearly 10 years now, and while I'm still relatively young, I'm definitely not "entry-level" any more. I make more than the average "middle manager", but still significantly less than "top management".
Oh, and in case you think perhaps I'm "stuck" doing my job - actually no, I enjoy it. I've been offered 3 different "management" positions in my current company and have always turned them down. I write code, and I enjoy writing code - I know I would NOT enjoy dealing with departmental budgets, resource allocation and whatever else it is that I'm currently (thankfully) shielded from by management.
I do have a profile on LinkedIn and while it hasn't given me any direct benefit yet, I see no problem to post my professional life there, as it may come in handy in the future.
Re:You're afraid to send out a resume?
on
Linked In Or Out?
·
· Score: 1
Work is the horrible thing I do in order to have money to live my life.
Sounds like you need to find a better job... The moment I stop enjoying my work, I'll find something else to do. Life is too precious to waste so many hours doing something I don't enjoy.
You are, technically correct (the best kind of correct).
However, I think you might have actually missed my point (which admittedly I wasn't too clear on since I focused more on the specific case rather than the general concept). My point was that while you're absolutely correct that there are hard fundamental limits to certain kinds of problems, it is almost always possible to use ones imagination to come up with another solution without having to solve the expensive problem.
This of course does depend on what kind of development you're doing - someone writing an image processor for example will of course always come up against these problems and will have NO choice in the matter if he wants to implement certain kinds of image processing. However, if you're writing a specific bit of code to "blur an image" and you don't care HOW it gets blurred, only that it "looks good" (subjective, which in this case is good), you can play around with various different kinds of things until you find one that is both fast and gives the result you want. Compare this to "perform a specific blur function", where you're choosing the algorithm to use, not the final result.
If it makes you feel warm and fuzzy, I'll happily say, "Yep, you're right, and the other guy was wrong", but from a more practical viewpoint than theory, I do actually side with his statement in general.
And now you're adding a new concept, that the file you're working on isn't good for sending as-is. Instead there's a way to generate a "special version for sending to other people", magical in a way that most people won't understand, and with unclear distinctions from the kind you normally work on.
This should be handled by the application developer that defined the object. History, revisions, and undo levels are separate objects to "the current document" within the system, but to the user it appears as one thing. When they email it to someone, they're only emailing "the current document" (which other systems will see as a perfectly normal file)
But in the real world, NO-ONE needs to do the travelling salesman problem perfectly. You introduced an artificial barrier when you said, "no approximations allowed", simply because in the real world if I needed to do something like the travelling salesman problem on a large set (e.g. 100 cities), I wouldn't do it. I'd come up with something that's "good enough but not perfect", because it's almost certainly going to be faster to do it "slower" than wasting the time computing how to do it the "fastest". (e.g. If I can come up with a simple, but imperfect solution in 1 day to do it 20, and know that it would take more than 21 days to come up with a "perfect" solution, then I'll take the imperfect one, because the final result of computation plus actual "visits" is quicker. (actually, I can make an educated guess that even the perfect solution may take at least 10 days, so I wouldn't even accept to take 11 days to work it out))
It's in the summary for $DEITY's sake... From the user's perspective, things still look familiar - a desktop, directories, and file icons
From the user's perspective there ARE files - it just works a differently from the developer's perspective. Users don't worry about saving before they close their word processor - it's just "back again" next time they open it. They're probably still opening it by double-clicking on the "Letter to Mom" file which they found by opening their "Documents" folder though.
How do you find it to send it to your mom?
When they go to email the document, the object is wrapped up as a "file" and attached like any other attachment. What's the difference between a stream of bytes stored on a drive and a file? Nothing... it's just how you look at it. What this OS is doing (from the summary and articles) is simply making it much less work from the developers point of view how to write these - there should be no difference between "create a new object" and "write that object to disk". For the user, this means persistent files (open, edit, close - without the "save" step), but other than the save step being removed, they'll still follow the same paradigm that they always have.
Java, C#, PHP, Python are already more used than C/C++, aren't them?
Depends on the type of work you're talking about. I do C# as my day job, but my background is mainly C and C++. I recently attended a training course on VxWorks and had to work my mind back in to the "C" way of thinking... I was actually pretty happy by the end of the course, and for the kinds of things one would write on VxWorks (think robotics control etc), you REALLY wouldn't want to do it in something like C# - C is just MUCH more suited to that (especially with some of the nice stuff the VxWorks design gives you for that sort of thing, but that's another topic)
This is also entirely my own guesswork based on the description of the OS - I could be totally wrong.
And what happens when you have one file, er, object you may want to open with multiple apps? It didn't seem from the description like it would attach a single object to multiple app object graphs, just that it had easy IPC. So what happens when I want to open a JPG in my photo management app and then Photoshop?
It seems some people think it should open two object instances, however I'd actually expect some slightly different (and rather cool) behaviour...
You have a picture. This picture is stored as a stream of bytes on your drive (pretty much exactly like a file).
You open the picture in an image viewer. It reads through the bytes, interprets them as being a PNG file and shows it on your screen in "human viewable form".
You now open the same picture in your image editor. It also reads through the exact same bytes and shows them on your screen.
In your image editor, you change the picture to greyscale. The new greyscale byte stream is different to the bytestream that's currently on the disk, so it writes it back.
In your image viewer, the image currently appears unchanged, because it never checked for updates to what's on disk. But if you close it and re-open it (or press some kind of "refresh" button, or wait for an auto-refresh that's built in), you now see the greyscale image.
That's the best that I can explain my understanding of it from the perspective of traditional "files", however by having this all "automatic", the behaviour would only really be like this for programs written in a more traditional kind of way. For programs written or modified specifically for this OS, you could possibly even have your image editor updating "live" as you edit in the editor, because they're looking at exactly the same data, and (theoretically) the image editor would only be writing the changes back rather than the complete "file".
I do see several potential problems for this concept of course, including all kinds of nasty race conditions on object access (fun with being REALLY paranoid about semaphores, here we come (unless they're also "built in" for ALL object access?)), but they're not insurmountable problems really - they just require stepping much further away from the normal model of things that most of us are used to.
In many languages, you can easily serialize objects or trees of objects. I'm not sure how this differs much in the Phantom OS except that it is choosing when to serialize out to disc for you, but I don't really see that as being much simpler.
As far as I can tell, it's not all that different to doing it yourself, but I DO see it as being much simpler. Imagine, I write something like the following C# code: using System; using PhantomStuff;
namespace CountProg {
class Program
{
private long appcounter;
void Main()
{
CallToMagicalSystemThatTellsTheOSThatAParticularVariableIsPersistent(appcounter);
if(appcounter == null)
appcounter = 0;
appcounter++;
Console.WriteLine("You've run this program " + appcounter + " times!");
}
} }
When I start the program, the magical call with the long name reads back the current state of appcounter. If it never existed before, it's of course null from its creation. When appcounter is assigned a new value, it's written to disk (no special call needed). Each time I re-run this program, appcounter gets incremented. This code WITHOUT the magical call will al
So, analogies such as folders are necessarily only very rough analogies to start with. Now, what happens when the file you are putting in a symbolic folder is an.AVI or.MP3 and not a text file? You wouldn't store a pile of videotapes, or CDs, or LP records in a real manila folder! An already stressed analogy now becomes less useful and more strained.
AmigaOS has a system called "Workbench". It's of course exactly the same concept, but the naming is slightly different to fit around the metaphor of a real physical workbench. Data that you work on (text, pictures, movies etc) are "Projects", programs are either "Tools" (programs for editing projects) or "Utilities" (programs that basically stand alone) and directories are "Drawers". So, you "open a drawer and start using a tool to work on a project (which is probably stored in a different drawer)". I always rather liked the metaphor there compared to the whole "office" feeling with folders and files. It's still not perfect of course, but it's got a sort of charm to it.
(to clarify the difference between "Tool" and "Utility" since that is different to Windows/Linux/MacOS - a Tool can take a Project as an argument, or if it has a GUI, will have some kind of "Open" option; whereas a Utility definitely won't. Your network stack is a Utility. Your keyboard remapper is a Utility. GIMP, OpenOffice and Emacs are all Tools. It gets a little "grey" when talking about things like the "list" command (equivalent of ls) but when using it from the commandline, the OS doesn't actually make a distinction anyway - the separation is mainly to handle things differently from the UI perspective.
circumcised is way better.... I'm glad it happened back when I can't remember it.
So how do you know it's better? The vast majority of men who have been circumcised later in life (late enough to have experienced "pleasures of the flesh" before and after) say that it was way better before. (However, even that's not a conclusive argument, since perhaps the process affects you differently later in life.)
The ladies love it!
And THAT depends where you live... in this part of the world, it'd make most girls say something like, "That looks so weird! I didn't know you were Jewish..." (most people in Europe are not circumcised unless they're Jewish)
And, to reply to your first statement last:
Dude you should try it some time
Being an irreversible process, I'd rather not chance it...
Just sort of have to throw my two cents on to this as well and agree whole-heartedly. I FAR prefer native GUI front ends on whatever platform to a web app. For most big web apps, they tend to be a basic form or two with "complex" stuff being called behind the scenes, in which case all of the real programming work went in to that "behind the scenes" stuff and that's not what I'd call a web app either.
I'm actually even considering going to the trouble of coding my own front ends for some internal web apps at work just because it's SO much faster to have a native client making calls to the back end DB than it is to wait for a buggy IE only webapp to do its thing and spawn a thousand or so annoying windows (especially ones that open with some text along the lines of "please wait", after which it opens another window, and closes the first, at which point IE pops up a requester warning me that the page is trying to close the window and do I want to allow it or not).
Many job ads don't specifically mention mono... we were advertising not so long ago (unfortunately, my new boss decided we'd be better pulling resources from elsewhere inside the company instead of hiring someone new, which still annoys me a little), and I don't think our job ad mentioned Mono at all... it just asked for ".NET development" and skills in "Windows, Linux and MacOS X", which pretty much implies mono development will be done of course, but wouldn't show up on a trends graph.
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original. Even if.Net is technical nirvana, if your platform's only implementation comes from a third party, your platform is a second-class citizen.
Only if you care about or need the "latest whizz-bang features". For most serious development I've never needed anything over.NET 2.0 so far, which Mono implements very admirably (plus a bit more).
Yes, it does mean I need to be a little more careful if I want things to run cross-platform - mono isn't in itself a final solution for cross platform stuff, and it's VERY possible to write Windows only code, Linux only code or even MacOS only code when using the.NET Framework and/or mono, but if you're targetting being cross-platform it really isn't too hard to do, and you definitely don't feel "second class" with the current mono versions (definitely did before there was much.NET 2.0 support, but because everything above that is "fluff" to someone developing core back-end stuff, there's been plenty of time for catch-up on the stuff that matters).
(.NET/Mono is already pretty awesome even for projects that require native libraries, though. Package libfoo.dll and libfoo.so in with your executable and assemblies, and it will intelligently grab the right one on Linux/Windows. Not so easy on BSD, Solaris, or OS X, but those really aren't primary platforms for that particular effort.)
Actually, it is just as easy on MacOS X. My company's SDK is.NET based, and we provide a "Mono version" for both OS X and Linux. Of course, the.NET assemblies themselves are the same, but there's just a couple of parts that are platform specific, which here we'll just call "libfoo". I can package in "libfoo.dll", "libfoo.so" and "libfoo.dylib", and it happily works on Windows, Linux and OS X. Not sure about the BSD and Solaris worlds though. Worst case scenario, it should be trivial enough to check for the native library and then manually call the right one, as long as DLLImport can handle it. I haven't stepped off the Windows/Linux/MacOS line yet when it comes to.NET, so I haven't really looked in to what's possible and what isn't.
Certainly not likely to work on Mac's or various phone platforms.
I use it on a Mac... professionally... My only complaint with it on MacOS is that I can't reasonably expect an end user to have mono, and so I tend to include the whole thing in to the one package, which makes for amazingly large looking programs when the basic functionality is so small (especially when I've just migrated a Windows app that was only a "few hundred KB" (as far as "migrating" goes - my Windows.NET apps do "just run" on mono, as that's actually one of my strict requirements at my workplace, but I prefer to write a native GUI in Cocoa# since WinForms or GTK look ghastly on a Mac)
I write.NET code and support other developers doing the same as my day job, and we fully support mono. In fact, one product that's due for release soon by a third party that I support is running mono on a headless linux box (it's intended as a sort of "black box" from the customers point of view - the choice was made for Linux and Mono purely because of price - this thing is to be MASS distributed, so Windows licenses would bump up the price too much). This product will be very widely used by our customers, so to me at least, it's clear that mono is mature enough now to be used in the 'real world'.
As far as developing it without Visual Studio - I use VS at work (although still on VS2005 - haven't found a compelling reason to upgrade yet), but at home, where I also do a lot of work when I can't be bothered heading in to the office, I use MonoDevelop. And, for Mac Specific projects, I generally write my back-end in MonoDevelop, compile as DLL(s) and then write the GUI with XCode (Cocoa#). I think I COULD do it with a plain ol' text-editor and get by okay, but I prefer to use a real IDE. With MonoDevelop existing though, Visual Studio is definitely NOT a requirement.
As a trained and qualified Private Investigator (in a country/state that requires licensing for PIs), I can definitively say that 99% of surveillance is incredibly dull. The remaining 1% more than makes up for it though and is amazingly fun way to earn a whole crapload of cash.
On that note though, I don't actually do it as my day job any more - I prefer being a software developer (the pay isn't as good, but it's more regular, and I don't have to deal with emotional people as often). I might go back to it one day if I get sick of staring at code all the time.
Wow... now that's a sorry state of affairs... that really should be more like a 2 minute task I would have thought.
Just to make sure I wasn't missing some subtlety of how it's done, I happened to have Visual Studio open the other window (yeh, I'm slashdotting at work) and in C# it took me less than one minute to write it... definitely no subtleties to it - it IS as simple as it sounds. (might've taken me 2 minutes C++ or C, just because in C# I can be a bit lazier about some things)
You're not asking them to do so in some horrible archaic and painful language are you? Or do you have any extra requirements, such as "must correctly proceed past a certain number of iterations" (making sure that said number is larger than an int or long on the target system (using a long in the test I just did, it starts going wrong a just a bit before the hundredth iteration))?
You write a few coding exercises, stuff that would take a "good" coder probably 5-10 minutes.
Are the exercises based around arcane theory, or "real world" stuff? I'm pretty confident I COULD sit and write nice, fast sorting algorithms (for example) for different kinds of data, but I'd have to dig through the old grey matter to remember the theory for a lot of it. I've got some sorting algorithms in a bunch of classes that I use in my projects, and when I need one, I just call it. In the real world, you do those things exactly ONCE (per new piece of arcane theory you need to implement) and then never again. For a small (sub one-day work) app, I tend to spend MORE time worrying about things like "making sure the user can't click the button if the fields aren't filled in correctly" or "making sure the user can't break things even if he tries" than I do on the fancy back-end stuff. It may be less interesting than the back-end fun stuff (which I spend most of my time working on on the bigger apps of course), but in the final delivered product, it makes the difference between an app that people consider "weird and confusing" vs "straightforward and elegant".
Of course, it also really depends what you're hiring the coders for - if they're ONLY doing one particular kind of work, then I guess it'd be pretty easy for you to tailor your exercises around that, but I've yet to come across such a job. My "day to day" is our company's own API, and mostly back-end "implementing the theory" kind of stuff, but I also tend to do quite a bit of "Hey, Yttrium Oxide, think you can write a quick app to do x, y and z for us?", which is often completely outside my standard day-to-day work (the post I just wrote above having a good example of that sort of thing)
Being good includes the ability to handle office politics successfully. Jobs that don't require office politics are incredibly rare.
If you can't find anybody in your old company that likes you, you probably need to work on your social skills. It's one of the things employers need to make sure the job gets done.
I feel "like" is probably the wrong word. I'm relatively well liked at my company (in that, I have friends from work that I also socialise with outside of work, including my superiors), but I don't attribute this as being as helpful as the "respect" that I have within the company. When you're seen as someone who can be a "saviour" for a particular problem (which those of us in IT can often do - in many different areas of IT), it tends to earn you respect, and when management notice that, you're much less likely to go on the chopping block.
Just as an example: Yesterday morning I wrote a small program, completely from scratch, that opens PNG files, modifies a few bytes to make it compatible with a weird system that doesn't like normal PNGs and then saves it again. Writing this was of course totally trivial and I don't consider it to be anything special - pretty much anyone who's just learning to code could have written the same. However by doing this, I just gave a point and click UI (even with fancy "preview" that scales to the window, blah-blah-blah) to a bunch of non-geeks who previously had instructions that told them to open a hex editor... That is viewed as "amazing" by non-programmers and earned me yet more "cred" in the company as someone who can make everyone else's lives easier.
Rule No. 1: You may be good. But there is always someone better.
Unless you find yourself a niche that is so obscure, there are an insanely small number of people who know the subject. For example: In my job, I deal with a custom API written by our company. This API makes custom calls to a custom system and while parts of it are based on standards like SOAP, other parts of it are just incredibly unique and completely indecipherable to anyone who hasn't deliberately spent time studying it.
Now, I know anyone COULD come along and study it, and if they're a better programmer than me (which I'll readily admit that MANY people are) they'll be better at dealing with it than me, but until such a time, I'm quite confident in saying that I am quite simply the best in the world at what I do. Admittedly, there's only about 4 people in the world that do what I do, so all I'm saying is that I'm better than the other 3, and if the technology is ever killed, I have a LARGE amount of COMPLETELY useless knowledge, but for the time being, it's a pretty good situation!
(note: I do know developers that are better than me, and some of them know a fair bit about our API (because I trained them on it), but they don't know "all" the details, and they work with it in totally different ways to myself, so even though I'll readily admit they're better developers, I don't consider them "better at doing what I do" because they don't do it.)
So if you build and deploy apps for macosx and linux, you're using mono. Why did you bother updating your.NET to 3.5 SP1 at all?
Most of my apps are "cross platform" using mono, but some aren't... And it's always good to stay across the latest developments, even if I won't use them immediately.
If it's going to kill you to have a Microsoft-authored ff extension, you can remove it (read the wikipedia link I referenced).
Yep, and I'm all for having such extensions available, I didn't uninstall it, and potentially may even use it one day (absolutely no need for it right now though) - what I'm not in favour of is it being installed without my knowledge/permission.
I think that the problem here is that the update shouldn't have been treated as a "high priority" update, since there are those who did not want the.net framework 3.5.
Actually, I think a nicer solution would have been to simply make it a separate update. There is no good reason that this "feature" needs to be a PART of the.NET update, regardless of the version. Let me install.NET Framework x.x and any associated SPx to it, but let me UNSELECT things I don't want from that, such as plugins to my browser, which has nothing to do with what I use.NET for.
One can only assume if you install.NET, you might actually want to run.NET apps, and some of them are deployed using ClickOnce.
But MANY aren't... That's like saying "One can only assume that if you install GIMP, you might actually want to use the GIMP, and some people use it for doing distortions based on mathematical formulae, so you shouldn't complain when MathMap gets installed automatically.". AND that's not even taking in to account the bigger and nastier complaint that Microsoft should have no right to force an install of something in to software that they didn't write, just because someone agreed to get updates automatically for software that they did write. (the user agreed to Microsoft updates to Microsoft software, NOT to Microsoft updating anything else)
In my day job, I write.NET based software. I "don't do web apps" at all (everything I write has GUI front ends done in WinForms, Cocoa# and/or GTK# (for MacOS X and Linux systems respectively)). We don't deploy anything via ClickOnce. Why do I need/want this in my Firefox? For my job, I tend to always stay on top of.NET updates in Windows and so installed this update on my test box for a bit of eval before putting it on my main dev system. My test box doesn't have Firefox and so I never noticed this at all... it was "surprise time" when I did install it on my main development system after that!
Slashdot Mirror
My girlfriend's company cut pay by 5% across the board. Ironically, this actually INCREASED her paycheck, as it bumped her into a lower tax bracket.
Hmmm... what country are you in? In every country I've ever lived in, the tax brackets are staged so that "up to x" you pay y%, and only for the amount OVER x do you pay z%... this ensures that such a thing could never happen (getting a "payrise" and ending up with less sounds a little crazy)
For IT people, places like facebook, and myspace are the place to go, since their careers are still in the entry-level phase.
You have an odd definition of "IT people"... I've been working in "IT" for nearly 10 years now, and while I'm still relatively young, I'm definitely not "entry-level" any more. I make more than the average "middle manager", but still significantly less than "top management".
Oh, and in case you think perhaps I'm "stuck" doing my job - actually no, I enjoy it. I've been offered 3 different "management" positions in my current company and have always turned them down. I write code, and I enjoy writing code - I know I would NOT enjoy dealing with departmental budgets, resource allocation and whatever else it is that I'm currently (thankfully) shielded from by management.
I do have a profile on LinkedIn and while it hasn't given me any direct benefit yet, I see no problem to post my professional life there, as it may come in handy in the future.
Work is the horrible thing I do in order to have money to live my life.
Sounds like you need to find a better job... The moment I stop enjoying my work, I'll find something else to do. Life is too precious to waste so many hours doing something I don't enjoy.
You are, technically correct (the best kind of correct).
However, I think you might have actually missed my point (which admittedly I wasn't too clear on since I focused more on the specific case rather than the general concept). My point was that while you're absolutely correct that there are hard fundamental limits to certain kinds of problems, it is almost always possible to use ones imagination to come up with another solution without having to solve the expensive problem.
This of course does depend on what kind of development you're doing - someone writing an image processor for example will of course always come up against these problems and will have NO choice in the matter if he wants to implement certain kinds of image processing. However, if you're writing a specific bit of code to "blur an image" and you don't care HOW it gets blurred, only that it "looks good" (subjective, which in this case is good), you can play around with various different kinds of things until you find one that is both fast and gives the result you want. Compare this to "perform a specific blur function", where you're choosing the algorithm to use, not the final result.
If it makes you feel warm and fuzzy, I'll happily say, "Yep, you're right, and the other guy was wrong", but from a more practical viewpoint than theory, I do actually side with his statement in general.
And now you're adding a new concept, that the file you're working on isn't good for sending as-is. Instead there's a way to generate a "special version for sending to other people", magical in a way that most people won't understand, and with unclear distinctions from the kind you normally work on.
This should be handled by the application developer that defined the object. History, revisions, and undo levels are separate objects to "the current document" within the system, but to the user it appears as one thing. When they email it to someone, they're only emailing "the current document" (which other systems will see as a perfectly normal file)
Well, take the travelling salesman problem
But in the real world, NO-ONE needs to do the travelling salesman problem perfectly. You introduced an artificial barrier when you said, "no approximations allowed", simply because in the real world if I needed to do something like the travelling salesman problem on a large set (e.g. 100 cities), I wouldn't do it. I'd come up with something that's "good enough but not perfect", because it's almost certainly going to be faster to do it "slower" than wasting the time computing how to do it the "fastest". (e.g. If I can come up with a simple, but imperfect solution in 1 day to do it 20, and know that it would take more than 21 days to come up with a "perfect" solution, then I'll take the imperfect one, because the final result of computation plus actual "visits" is quicker. (actually, I can make an educated guess that even the perfect solution may take at least 10 days, so I wouldn't even accept to take 11 days to work it out))
It's in the summary for $DEITY's sake... From the user's perspective, things still look familiar - a desktop, directories, and file icons
From the user's perspective there ARE files - it just works a differently from the developer's perspective. Users don't worry about saving before they close their word processor - it's just "back again" next time they open it. They're probably still opening it by double-clicking on the "Letter to Mom" file which they found by opening their "Documents" folder though.
How do you find it to send it to your mom?
When they go to email the document, the object is wrapped up as a "file" and attached like any other attachment. What's the difference between a stream of bytes stored on a drive and a file? Nothing... it's just how you look at it. What this OS is doing (from the summary and articles) is simply making it much less work from the developers point of view how to write these - there should be no difference between "create a new object" and "write that object to disk". For the user, this means persistent files (open, edit, close - without the "save" step), but other than the save step being removed, they'll still follow the same paradigm that they always have.
Java, C#, PHP, Python are already more used than C/C++, aren't them?
Depends on the type of work you're talking about. I do C# as my day job, but my background is mainly C and C++. I recently attended a training course on VxWorks and had to work my mind back in to the "C" way of thinking... I was actually pretty happy by the end of the course, and for the kinds of things one would write on VxWorks (think robotics control etc), you REALLY wouldn't want to do it in something like C# - C is just MUCH more suited to that (especially with some of the nice stuff the VxWorks design gives you for that sort of thing, but that's another topic)
This is also entirely my own guesswork based on the description of the OS - I could be totally wrong.
And what happens when you have one file, er, object you may want to open with multiple apps? It didn't seem from the description like it would attach a single object to multiple app object graphs, just that it had easy IPC. So what happens when I want to open a JPG in my photo management app and then Photoshop?
It seems some people think it should open two object instances, however I'd actually expect some slightly different (and rather cool) behaviour...
That's the best that I can explain my understanding of it from the perspective of traditional "files", however by having this all "automatic", the behaviour would only really be like this for programs written in a more traditional kind of way. For programs written or modified specifically for this OS, you could possibly even have your image editor updating "live" as you edit in the editor, because they're looking at exactly the same data, and (theoretically) the image editor would only be writing the changes back rather than the complete "file".
I do see several potential problems for this concept of course, including all kinds of nasty race conditions on object access (fun with being REALLY paranoid about semaphores, here we come (unless they're also "built in" for ALL object access?)), but they're not insurmountable problems really - they just require stepping much further away from the normal model of things that most of us are used to.
In many languages, you can easily serialize objects or trees of objects. I'm not sure how this differs much in the Phantom OS except that it is choosing when to serialize out to disc for you, but I don't really see that as being much simpler.
As far as I can tell, it's not all that different to doing it yourself, but I DO see it as being much simpler. Imagine, I write something like the following C# code:
using System;
using PhantomStuff;
namespace CountProg
{
class Program
{
private long appcounter;
void Main()
{
CallToMagicalSystemThatTellsTheOSThatAParticularVariableIsPersistent(appcounter);
if(appcounter == null)
appcounter = 0;
appcounter++;
Console.WriteLine("You've run this program " + appcounter + " times!");
}
}
}
When I start the program, the magical call with the long name reads back the current state of appcounter. If it never existed before, it's of course null from its creation. When appcounter is assigned a new value, it's written to disk (no special call needed). Each time I re-run this program, appcounter gets incremented. This code WITHOUT the magical call will al
So, analogies such as folders are necessarily only very rough analogies to start with. Now, what happens when the file you are putting in a symbolic folder is an .AVI or .MP3 and not a text file? You wouldn't store a pile of videotapes, or CDs, or LP records in a real manila folder! An already stressed analogy now becomes less useful and more strained.
AmigaOS has a system called "Workbench". It's of course exactly the same concept, but the naming is slightly different to fit around the metaphor of a real physical workbench. Data that you work on (text, pictures, movies etc) are "Projects", programs are either "Tools" (programs for editing projects) or "Utilities" (programs that basically stand alone) and directories are "Drawers". So, you "open a drawer and start using a tool to work on a project (which is probably stored in a different drawer)". I always rather liked the metaphor there compared to the whole "office" feeling with folders and files. It's still not perfect of course, but it's got a sort of charm to it.
(to clarify the difference between "Tool" and "Utility" since that is different to Windows/Linux/MacOS - a Tool can take a Project as an argument, or if it has a GUI, will have some kind of "Open" option; whereas a Utility definitely won't. Your network stack is a Utility. Your keyboard remapper is a Utility. GIMP, OpenOffice and Emacs are all Tools.
It gets a little "grey" when talking about things like the "list" command (equivalent of ls) but when using it from the commandline, the OS doesn't actually make a distinction anyway - the separation is mainly to handle things differently from the UI perspective.
circumcised is way better .... I'm glad it happened back when I can't remember it.
So how do you know it's better? The vast majority of men who have been circumcised later in life (late enough to have experienced "pleasures of the flesh" before and after) say that it was way better before. (However, even that's not a conclusive argument, since perhaps the process affects you differently later in life.)
The ladies love it!
And THAT depends where you live... in this part of the world, it'd make most girls say something like, "That looks so weird! I didn't know you were Jewish..." (most people in Europe are not circumcised unless they're Jewish)
And, to reply to your first statement last:
Dude you should try it some time
Being an irreversible process, I'd rather not chance it...
Just sort of have to throw my two cents on to this as well and agree whole-heartedly. I FAR prefer native GUI front ends on whatever platform to a web app. For most big web apps, they tend to be a basic form or two with "complex" stuff being called behind the scenes, in which case all of the real programming work went in to that "behind the scenes" stuff and that's not what I'd call a web app either.
I'm actually even considering going to the trouble of coding my own front ends for some internal web apps at work just because it's SO much faster to have a native client making calls to the back end DB than it is to wait for a buggy IE only webapp to do its thing and spawn a thousand or so annoying windows (especially ones that open with some text along the lines of "please wait", after which it opens another window, and closes the first, at which point IE pops up a requester warning me that the page is trying to close the window and do I want to allow it or not).
Many job ads don't specifically mention mono... we were advertising not so long ago (unfortunately, my new boss decided we'd be better pulling resources from elsewhere inside the company instead of hiring someone new, which still annoys me a little), and I don't think our job ad mentioned Mono at all... it just asked for ".NET development" and skills in "Windows, Linux and MacOS X", which pretty much implies mono development will be done of course, but wouldn't show up on a trends graph.
A third party implementation of a standard defined by the first-party implementor is always going to lag behind the original. Even if .Net is technical nirvana, if your platform's only implementation comes from a third party, your platform is a second-class citizen.
Only if you care about or need the "latest whizz-bang features". For most serious development I've never needed anything over .NET 2.0 so far, which Mono implements very admirably (plus a bit more).
Yes, it does mean I need to be a little more careful if I want things to run cross-platform - mono isn't in itself a final solution for cross platform stuff, and it's VERY possible to write Windows only code, Linux only code or even MacOS only code when using the .NET Framework and/or mono, but if you're targetting being cross-platform it really isn't too hard to do, and you definitely don't feel "second class" with the current mono versions (definitely did before there was much .NET 2.0 support, but because everything above that is "fluff" to someone developing core back-end stuff, there's been plenty of time for catch-up on the stuff that matters).
(.NET/Mono is already pretty awesome even for projects that require native libraries, though. Package libfoo.dll and libfoo.so in with your executable and assemblies, and it will intelligently grab the right one on Linux/Windows. Not so easy on BSD, Solaris, or OS X, but those really aren't primary platforms for that particular effort.)
Actually, it is just as easy on MacOS X. My company's SDK is .NET based, and we provide a "Mono version" for both OS X and Linux. Of course, the .NET assemblies themselves are the same, but there's just a couple of parts that are platform specific, which here we'll just call "libfoo". I can package in "libfoo.dll", "libfoo.so" and "libfoo.dylib", and it happily works on Windows, Linux and OS X. Not sure about the BSD and Solaris worlds though. Worst case scenario, it should be trivial enough to check for the native library and then manually call the right one, as long as DLLImport can handle it. I haven't stepped off the Windows/Linux/MacOS line yet when it comes to .NET, so I haven't really looked in to what's possible and what isn't.
Certainly not likely to work on Mac's or various phone platforms.
I use it on a Mac... professionally... My only complaint with it on MacOS is that I can't reasonably expect an end user to have mono, and so I tend to include the whole thing in to the one package, which makes for amazingly large looking programs when the basic functionality is so small (especially when I've just migrated a Windows app that was only a "few hundred KB" (as far as "migrating" goes - my Windows .NET apps do "just run" on mono, as that's actually one of my strict requirements at my workplace, but I prefer to write a native GUI in Cocoa# since WinForms or GTK look ghastly on a Mac)
I write .NET code and support other developers doing the same as my day job, and we fully support mono. In fact, one product that's due for release soon by a third party that I support is running mono on a headless linux box (it's intended as a sort of "black box" from the customers point of view - the choice was made for Linux and Mono purely because of price - this thing is to be MASS distributed, so Windows licenses would bump up the price too much). This product will be very widely used by our customers, so to me at least, it's clear that mono is mature enough now to be used in the 'real world'.
As far as developing it without Visual Studio - I use VS at work (although still on VS2005 - haven't found a compelling reason to upgrade yet), but at home, where I also do a lot of work when I can't be bothered heading in to the office, I use MonoDevelop. And, for Mac Specific projects, I generally write my back-end in MonoDevelop, compile as DLL(s) and then write the GUI with XCode (Cocoa#). I think I COULD do it with a plain ol' text-editor and get by okay, but I prefer to use a real IDE. With MonoDevelop existing though, Visual Studio is definitely NOT a requirement.
As a trained and qualified Private Investigator (in a country/state that requires licensing for PIs), I can definitively say that 99% of surveillance is incredibly dull. The remaining 1% more than makes up for it though and is amazingly fun way to earn a whole crapload of cash.
On that note though, I don't actually do it as my day job any more - I prefer being a software developer (the pay isn't as good, but it's more regular, and I don't have to deal with emotional people as often). I might go back to it one day if I get sick of staring at code all the time.
Wow... now that's a sorry state of affairs... that really should be more like a 2 minute task I would have thought.
Just to make sure I wasn't missing some subtlety of how it's done, I happened to have Visual Studio open the other window (yeh, I'm slashdotting at work) and in C# it took me less than one minute to write it... definitely no subtleties to it - it IS as simple as it sounds. (might've taken me 2 minutes C++ or C, just because in C# I can be a bit lazier about some things)
You're not asking them to do so in some horrible archaic and painful language are you? Or do you have any extra requirements, such as "must correctly proceed past a certain number of iterations" (making sure that said number is larger than an int or long on the target system (using a long in the test I just did, it starts going wrong a just a bit before the hundredth iteration))?
You write a few coding exercises, stuff that would take a "good" coder probably 5-10 minutes.
Are the exercises based around arcane theory, or "real world" stuff? I'm pretty confident I COULD sit and write nice, fast sorting algorithms (for example) for different kinds of data, but I'd have to dig through the old grey matter to remember the theory for a lot of it. I've got some sorting algorithms in a bunch of classes that I use in my projects, and when I need one, I just call it. In the real world, you do those things exactly ONCE (per new piece of arcane theory you need to implement) and then never again. For a small (sub one-day work) app, I tend to spend MORE time worrying about things like "making sure the user can't click the button if the fields aren't filled in correctly" or "making sure the user can't break things even if he tries" than I do on the fancy back-end stuff. It may be less interesting than the back-end fun stuff (which I spend most of my time working on on the bigger apps of course), but in the final delivered product, it makes the difference between an app that people consider "weird and confusing" vs "straightforward and elegant".
Of course, it also really depends what you're hiring the coders for - if they're ONLY doing one particular kind of work, then I guess it'd be pretty easy for you to tailor your exercises around that, but I've yet to come across such a job. My "day to day" is our company's own API, and mostly back-end "implementing the theory" kind of stuff, but I also tend to do quite a bit of "Hey, Yttrium Oxide, think you can write a quick app to do x, y and z for us?", which is often completely outside my standard day-to-day work (the post I just wrote above having a good example of that sort of thing)
Being good includes the ability to handle office politics successfully. Jobs that don't require office politics are incredibly rare.
If you can't find anybody in your old company that likes you, you probably need to work on your social skills. It's one of the things employers need to make sure the job gets done.
I feel "like" is probably the wrong word. I'm relatively well liked at my company (in that, I have friends from work that I also socialise with outside of work, including my superiors), but I don't attribute this as being as helpful as the "respect" that I have within the company. When you're seen as someone who can be a "saviour" for a particular problem (which those of us in IT can often do - in many different areas of IT), it tends to earn you respect, and when management notice that, you're much less likely to go on the chopping block.
Just as an example: Yesterday morning I wrote a small program, completely from scratch, that opens PNG files, modifies a few bytes to make it compatible with a weird system that doesn't like normal PNGs and then saves it again. Writing this was of course totally trivial and I don't consider it to be anything special - pretty much anyone who's just learning to code could have written the same. However by doing this, I just gave a point and click UI (even with fancy "preview" that scales to the window, blah-blah-blah) to a bunch of non-geeks who previously had instructions that told them to open a hex editor... That is viewed as "amazing" by non-programmers and earned me yet more "cred" in the company as someone who can make everyone else's lives easier.
Rule No. 1: You may be good. But there is always someone better.
Unless you find yourself a niche that is so obscure, there are an insanely small number of people who know the subject. For example: In my job, I deal with a custom API written by our company. This API makes custom calls to a custom system and while parts of it are based on standards like SOAP, other parts of it are just incredibly unique and completely indecipherable to anyone who hasn't deliberately spent time studying it.
Now, I know anyone COULD come along and study it, and if they're a better programmer than me (which I'll readily admit that MANY people are) they'll be better at dealing with it than me, but until such a time, I'm quite confident in saying that I am quite simply the best in the world at what I do. Admittedly, there's only about 4 people in the world that do what I do, so all I'm saying is that I'm better than the other 3, and if the technology is ever killed, I have a LARGE amount of COMPLETELY useless knowledge, but for the time being, it's a pretty good situation!
(note: I do know developers that are better than me, and some of them know a fair bit about our API (because I trained them on it), but they don't know "all" the details, and they work with it in totally different ways to myself, so even though I'll readily admit they're better developers, I don't consider them "better at doing what I do" because they don't do it.)
So if you build and deploy apps for macosx and linux, you're using mono. Why did you bother updating your .NET to 3.5 SP1 at all?
Most of my apps are "cross platform" using mono, but some aren't... And it's always good to stay across the latest developments, even if I won't use them immediately.
If it's going to kill you to have a Microsoft-authored ff extension, you can remove it (read the wikipedia link I referenced).
Yep, and I'm all for having such extensions available, I didn't uninstall it, and potentially may even use it one day (absolutely no need for it right now though) - what I'm not in favour of is it being installed without my knowledge/permission.
I think that the problem here is that the update shouldn't have been treated as a "high priority" update, since there are those who did not want the .net framework 3.5.
Actually, I think a nicer solution would have been to simply make it a separate update. There is no good reason that this "feature" needs to be a PART of the .NET update, regardless of the version. Let me install .NET Framework x.x and any associated SPx to it, but let me UNSELECT things I don't want from that, such as plugins to my browser, which has nothing to do with what I use .NET for.
One can only assume if you install .NET, you might actually want to run .NET apps, and some of them are deployed using ClickOnce.
But MANY aren't... That's like saying "One can only assume that if you install GIMP, you might actually want to use the GIMP, and some people use it for doing distortions based on mathematical formulae, so you shouldn't complain when MathMap gets installed automatically.". AND that's not even taking in to account the bigger and nastier complaint that Microsoft should have no right to force an install of something in to software that they didn't write, just because someone agreed to get updates automatically for software that they did write. (the user agreed to Microsoft updates to Microsoft software, NOT to Microsoft updating anything else)
In my day job, I write .NET based software. I "don't do web apps" at all (everything I write has GUI front ends done in WinForms, Cocoa# and/or GTK# (for MacOS X and Linux systems respectively)). We don't deploy anything via ClickOnce. Why do I need/want this in my Firefox? For my job, I tend to always stay on top of .NET updates in Windows and so installed this update on my test box for a bit of eval before putting it on my main dev system. My test box doesn't have Firefox and so I never noticed this at all... it was "surprise time" when I did install it on my main development system after that!