I would suggest you start on 3D printing as that has the most intuitive manufacturing paradigm (YMMV but still...).
The easiest solid modeler to learn is probably Tinkercad: https://tinkercad.com/.
Blender and Sketchup are not solid modelers. They CAN produce manufacturable (i.e watertight) meshes if you know what you want from them, though.
I would suggest you try 3D printing with Tinkercad to get your bearings and then figure out where to go next.
So nobody should have any legal rights to any reproducible content, for any span of time? I urge you to reconsider your position, mate. And also the fellows who upvoted this.
Intellectual property as a concept means that a creative person has at least a chance of make a living out of her/his awesome stuff. Without any ip laws, the end product could be immediately after its risen popularity copied and reproduced by some enterprising gnome. Not that the money flows are not controlled by gnomes, but with ip laws the artist has a chance to earn bread and enjoy success in the rare occasions. What is completely arsewise is the improper magnitude of the enforcement of this as some parties seek, and the fact that national political entities succumb to this maddness. There are indecent things out there, but minimal ip that makea sense is not one pf the, imho. The current levels of enforcement and the level of entitelment sought by the ip holders are crazy, but that does not invalidate the concept. Its just an example what happens when legal bodies either lack the wisdom or are lured by the powerfull with shiny things.
I have a fairly good clue of what's going on since the company I work for (Tekla) got recently acquired by Trimble. Except for long term roadmap, they've pretty much left us alone (at least it seems that way to us programmers).
Trimble wants to create a competetive vertical solution in the construction industry to compete with Autodesk's toolchain. Autodesk pretty much dominates the construction industry, and their ecosystem is proprietary and closed.
The counterbalance to this is a developing toolchain of tools built around the IFC format which is standardized and open. Trimble already had most of the other pieces in a complete architect-to-the-construction yard toolchain except for an archictecture software, and now they have it.
This means, there is now true competition in the construction segment offering information tools, and not only Autodesk and Autodesk. This sort of competition is good, people.At least so far the non-Autodesk parties try to break their dominant position with collaborative tools and an open format. Of course, what the situation will be in the future? Who knows.
This is probably due to the fact that very many young programmers are ever so keen to be in the business... Supply of labour is infinite, filled with enthusiastic young people who are inexperienced in standing up for themselves. With - lets face it - completely undefined end product and whose success is fairly unrelated to the input of the individual programmer. Thats probably why indie games sound like such a great proposition to anyone who is skiled enough to write their own code and design their own game. The first part is not the most difficult one, btw.
Btw. does anyone use IronPyhton and F#, or they just look good in PR blurbs?
Seriously, F# is awesome. These course notes and code examples explain why in far more detail than I ever could. http://www.itu.dk/courses/BPRD/E2010/.
Same use case. Love my Ipad. In a wlan network Readdledoc functions as a wireless file server that you can mount as a regular drive on any os, which is exactly what a caveman like myself who uses plain old file system operations for my document management needs. The downside is the IPad's somewhat clumsy overall file management imposed by the ios.
I've been working in the sofwtare industry since 2007 in a small team (individual projects ranging from 1 to 10 persons). We've always used scrum. Mind you, not by the book but heavily modified to fit our style. Seems to work if all participants are even a bit motivated and not totally clueless about the tasks at hand.
Software engineers should understand use case analys, user interface design, project management and finance, and many other important subjects "computer science" curricula ignore while beating students over the head with details theory. Understanding issues of scalability is good (though often actual testing is used in the engineering world for practical reasons), but we don't need four years of that while ignoring more important topics.
From the pragmatic point of view, there are two issues at play here. One - how to build decent programs that are maintainable and - two - understanding how such a program actually works.
If your skills lack in the former, your code is probably near-to-useless in the long term for anyone. If you lack in the second - THE HARDER PART (pardon my caps) - then you are just partaking in a cargo cult that just happens to work because someone left you the tools that luckily get you the job done.
I also think the second skillset requires a lot more effort to acquire than the first.
Concerning rote: It's necessary, but it's not everything. It's like learning to play an instrument. You have to memorize the notation used in sheet music, so you can follow compositions and communicate your ideas with everyone else. But the real music is happening at the instrument, you have to learn to play (rote here, again), then when you're proficient enough you can start making you're own interpretations, variations, and even maybe doing little composition.
Now, in maths you could compare learning the notes to understanding the notation and some basic concepts. But the point about passion was a good one: you have to work by yourself. You can compare the lectures to teaching you how to read sheet music, but to really learn how to play, you need to do real practice. Concerning that, there were some good points above. Also, what I like to do with problems that can be treated analytically, is to start looking at what the most simple solution to some equation looks like. Insert zeros, insert one and a zero..., look just at the first terms, maybe doodle some graphs... see how those behave to build up intuition on the problem, then go after the full scale beast of greek alphabetical soup looking at you on the page.
Think that you have to exercise your brain, as a muscle. It's a good analogue, anyway. Compare reading math books to reading an exercise manual. You can't get fit by just looking at those instructional images; you have to get to the floor, grind your teeth and start doing push ups / what ever. Reading about the beauty math in some nice books is probably a waste of time, at first. You'll see some of niceties yourself if you work hard. Compare this to reading a travel book about the Grand Canyon, and going rafting down it yourself. Not to say, that you shouldn't read those books. They just probably wont increase your math skills, not in the initial stages, anyway. You'll also enjoy the good books better, if you really understand beforehand what the writer is REALLY talking about.
It's going to be painful, but the upshot is that you can and probably will learn, if you have the will and discipline. You have to accept that the elementary practice stage is going to take some time, like a few years or something, before you can really play something neat. Then, perhaps at some point you might find some practical or abstract math related problem that you really enjoy thinking about, and at that point, it turns to intellectual joy. Don't read maths next to your computer. Find some desolate chair and a desk where you won't be interrupted. Collect enough non-digital reference material so you don't need to check some concept at wikipedia. If you suddenly notice that you don't understand something, go back to where you lost it, and start working again. Always have a pen and pencil, and do notes, while reading. Also, coming up with your own memorization rules will probably help a lot. Spatial, graphic, really silly poems... what ever seems to work best for you, you'll have to discover yourself. Some stuff you come across, cannot really be deduced except through some really loong proof that you are going to forget anyway. Do the proof once, so you see what's happening, and then accept the truth of it and use the memorized end result.
There's probably some point beyond which it's really difficult to increase your math skills but it's likely waaay ahead.
> Do you think that computer technicians can make a difference in the adoption of OSS? And if they're for OSS, should they try to put some pressure on their users/clients?
If price of a software product is not the problem, I'd say that the responsibility of a computer technician, as an engineer, would be to suggest, if he was questioned, to find the most cost effective solution to a particular task. Including the number of hours it would take work time for the new user to learn to use the software. Really, your main concern should be the productivity of the software and the maintainability. The cost of the software to an organization usually is neglible compared to the labor costs.
Sometimes free options are just fine and dandy, or even better than anything else. And sometimes you just don't have anything that compares to a commercial product (say, like Adobe's CS suite , some engineering FEM modeling software like Ansys). Learn the need, then find the best tool for the job. It's all process instructions to the computer, and the value to the end user is in the final product (a publication, report, memo, whatever), not the tool he used.
Well, this comment is kinda lateral (as in 'not related to opengl and games'), but I think you'd appreciate flipping through a few basic computer graphics books and related maths --- after all, opengl is just an implementation of the few of the most basic concepts and the red&blue books are mostly 'just' technical reference manuals. getting a handle of the basic concepts also probably clarifies what you actually want to do with the code.
Graphics:
watt&watt: Advanced Animation and Rendering Techniques - not a very recent book but the material is still relevant and the presentation of different concepts is relly good Hearn & Baker: Computer graphics (c or opengl version depending on your preferences). Basic computer graphics. Pretty good. The opengl version eschews some of the more basic code samples from the c version, which is a bit shame really. Moller & Haines: Real-Time Rendering - relevant for real time applications and contains great references to computer graphics resources in general
Geometry & linear algebra: Philip Schneider & David Eberly: geometric tools for computer graphics (contains recipes for eg. checking collisions, raytracing, clipping...). Might be not best book of this type(?) but it's ok.
The book's themselves are also excllent recipe repositories, but really useful only after you know the basic concepts from basic textbooks etc....and, if you have the access then the http://portal.acm.org/ stuff is really good. (search for 'siggraph "course notes" for starters') You can find details to most of the stuff Pixar, Alias etc. do from there...
If you have the time and resouces, then the Moller & Haines book is a decent roadmap to the field ("Oh, what's this...let's see the referred book/article has to say.. oh, that's interesting!") from the grass roots of z-buffers up to modern fps engine concepts.
But isn't it true that most of records of past CMEs are based on those directed towards earth? If they weren't at least somewhat in our direction, we'd be unlinkely to know about them
True. Some indicators for solar activity have been recorded for over a hundred years; the aforementioned magnetometer data and the sunspot number:
http://www.ngdc.noaa.gov/stp/IONO/sunspot.html
Also, prominences located at the edges of the visible "disk" of the sun have been observed probably as long as that: I found some nice modern day examples in here:
http://www.digilife.be/club/Franky.Dubois/world.ht m
But, none of these methods produce quantitative data of the precision or scope available today. One of the top instruments (well, intstrument platform actually)is the SOHO spacecraft launched in 1995 http://sohowww.nascom.nasa.gov/
There have probably been other solar observing satellites prior to soho, but I can't remember any specifics (anyone?).
So, yes, unless a particle storm from a CME event hit earth square in the face, so to speak, there would be no quantitative data of such an event older than... a handful of decades?
...both CMEs came from the same spot on the sun?
Yes, they did. The culprit is known as "sunspot 486". More data at www.spaceweather.com.
Is the sun's rotation much greater than 24 hours?
Actually, there's a latitudal variation to the angular speed of the sun's surface. The period of sun's rotation around solar equator is 29 (Earth)days. On the 60 latitude it's 25 days.
If, however, we do have 100+ years date on all CME events, we would be able to say that it's a statistical anomaly. I just think it's more likely that we don't understand enough about the sun's behavior to properly characerize this event.
I suppose it's an anomalous event in the scope of the recorded history of Earth's magnetic field data... True, to extend this probabilistic term to the entire lifespan and surface of the sun would be silly. But, you have to take in he human aspect of the situation; it's on of the biggest events monitored and recorded. It's a one thing to have the mathematical intuition that events of some magnitude are possible, and to actually witness one (ie. you know that it's possible to win lottery. But you don't, very often. At least I don't:) )
True, no all-encompassing solar models exist. Completely separated from it's context that quote does sound silly, ie. if we consider the probability of an eruption from the sun of the magnitude described here. However, when you factor in the chance that an such an eruption would also hit Earth, it really appears quite a rare event.
Also, data related to this event has been systematically accumulated for over a hundred years. Scientific measurements of Earth's magnetic field has been recorded in many observatories from the late 19th. century. Official date for the earliest data of magnetic storm is 1868.
As a primer to those unfamiliar with space weather phenomena,in short, the charged particles from the coronal mass ejection create currents in the earth's ionosphere (altitude of 100km-200km), which due to induction, disturb Earth's magnetic field.( So no outdoor solar grill-parties, I'm afraid.). These variations are used as an indicator in the measurements... the more wiggling of the magnetic needle, the more powerful the storm, so to speak. Alas, a regular compass is not precise enough to measure these variations.
Not only did the storm that hit earth yesterday create fluctuations in the field bigger than anything in 14 years (northward pointing field component variation of over 3000 nanoteslas in a span of few minutes at 60deg latitude in northern Europe), being the 15th. strongest storm in the recorded history, the same apparently happened tonight also.
So, what does it mean? Well, time-varying magnetic fields induce electric fields. Not extremly strong fields (maximum in the range of volts/km), but in long conductors even relatively weak fields can effect strong currents. 1989 most of Quebec's powergrid suffered a black-out due to these geomagnetically induced currents.
Now as it happened, the magnetic field in the yesterdays particle eruption was luckily beningly aligned- same direction as Earth's field, which deflected... buffeted...the particles... oh, it's complicated. Anyway, if the field had been pointed antiparallel to Earth's field, the particles would have flushed in in to ionosphere creating lot more of electromagnetic activity.
Well, enough of rambles. My point was that when you analyze the this event, it's not just about some single fluctuating random variable. And it's not rare just on the scope of some obscure numerological thingamajick of a model. Actually you've got a plenty of fluctuating variables...or something. And also a beautiful display of northern lights, if you're lucky.
Slashdot Mirror
I would suggest you start on 3D printing as that has the most intuitive manufacturing paradigm (YMMV but still...). The easiest solid modeler to learn is probably Tinkercad: https://tinkercad.com/. Blender and Sketchup are not solid modelers. They CAN produce manufacturable (i.e watertight) meshes if you know what you want from them, though. I would suggest you try 3D printing with Tinkercad to get your bearings and then figure out where to go next.
So nobody should have any legal rights to any reproducible content, for any span of time? I urge you to reconsider your position, mate. And also the fellows who upvoted this. Intellectual property as a concept means that a creative person has at least a chance of make a living out of her/his awesome stuff. Without any ip laws, the end product could be immediately after its risen popularity copied and reproduced by some enterprising gnome. Not that the money flows are not controlled by gnomes, but with ip laws the artist has a chance to earn bread and enjoy success in the rare occasions. What is completely arsewise is the improper magnitude of the enforcement of this as some parties seek, and the fact that national political entities succumb to this maddness. There are indecent things out there, but minimal ip that makea sense is not one pf the, imho. The current levels of enforcement and the level of entitelment sought by the ip holders are crazy, but that does not invalidate the concept. Its just an example what happens when legal bodies either lack the wisdom or are lured by the powerfull with shiny things.
I have a fairly good clue of what's going on since the company I work for (Tekla) got recently acquired by Trimble. Except for long term roadmap, they've pretty much left us alone (at least it seems that way to us programmers). Trimble wants to create a competetive vertical solution in the construction industry to compete with Autodesk's toolchain. Autodesk pretty much dominates the construction industry, and their ecosystem is proprietary and closed. The counterbalance to this is a developing toolchain of tools built around the IFC format which is standardized and open. Trimble already had most of the other pieces in a complete architect-to-the-construction yard toolchain except for an archictecture software, and now they have it. This means, there is now true competition in the construction segment offering information tools, and not only Autodesk and Autodesk. This sort of competition is good, people.At least so far the non-Autodesk parties try to break their dominant position with collaborative tools and an open format. Of course, what the situation will be in the future? Who knows.
This is probably due to the fact that very many young programmers are ever so keen to be in the business... Supply of labour is infinite, filled with enthusiastic young people who are inexperienced in standing up for themselves. With - lets face it - completely undefined end product and whose success is fairly unrelated to the input of the individual programmer. Thats probably why indie games sound like such a great proposition to anyone who is skiled enough to write their own code and design their own game. The first part is not the most difficult one, btw.
Btw. does anyone use IronPyhton and F#, or they just look good in PR blurbs?
Seriously, F# is awesome. These course notes and code examples explain why in far more detail than I ever could. http://www.itu.dk/courses/BPRD/E2010/.
Same use case. Love my Ipad. In a wlan network Readdledoc functions as a wireless file server that you can mount as a regular drive on any os, which is exactly what a caveman like myself who uses plain old file system operations for my document management needs. The downside is the IPad's somewhat clumsy overall file management imposed by the ios.
I've been working in the sofwtare industry since 2007 in a small team (individual projects ranging from 1 to 10 persons). We've always used scrum. Mind you, not by the book but heavily modified to fit our style. Seems to work if all participants are even a bit motivated and not totally clueless about the tasks at hand.
Software engineers should understand use case analys, user interface design, project management and finance, and many other important subjects "computer science" curricula ignore while beating students over the head with details theory. Understanding issues of scalability is good (though often actual testing is used in the engineering world for practical reasons), but we don't need four years of that while ignoring more important topics.
From the pragmatic point of view, there are two issues at play here. One - how to build decent programs that are maintainable and - two - understanding how such a program actually works. If your skills lack in the former, your code is probably near-to-useless in the long term for anyone. If you lack in the second - THE HARDER PART (pardon my caps) - then you are just partaking in a cargo cult that just happens to work because someone left you the tools that luckily get you the job done. I also think the second skillset requires a lot more effort to acquire than the first.
Now, in maths you could compare learning the notes to understanding the notation and some basic concepts. But the point about passion was a good one: you have to work by yourself. You can compare the lectures to teaching you how to read sheet music, but to really learn how to play, you need to do real practice. Concerning that, there were some good points above. Also, what I like to do with problems that can be treated analytically, is to start looking at what the most simple solution to some equation looks like. Insert zeros, insert one and a zero..., look just at the first terms, maybe doodle some graphs... see how those behave to build up intuition on the problem, then go after the full scale beast of greek alphabetical soup looking at you on the page.
Think that you have to exercise your brain, as a muscle. It's a good analogue, anyway. Compare reading math books to reading an exercise manual. You can't get fit by just looking at those instructional images; you have to get to the floor, grind your teeth and start doing push ups / what ever. Reading about the beauty math in some nice books is probably a waste of time, at first. You'll see some of niceties yourself if you work hard. Compare this to reading a travel book about the Grand Canyon, and going rafting down it yourself. Not to say, that you shouldn't read those books. They just probably wont increase your math skills, not in the initial stages, anyway. You'll also enjoy the good books better, if you really understand beforehand what the writer is REALLY talking about.
It's going to be painful, but the upshot is that you can and probably will learn, if you have the will and discipline. You have to accept that the elementary practice stage is going to take some time, like a few years or something, before you can really play something neat. Then, perhaps at some point you might find some practical or abstract math related problem that you really enjoy thinking about, and at that point, it turns to intellectual joy. Don't read maths next to your computer. Find some desolate chair and a desk where you won't be interrupted. Collect enough non-digital reference material so you don't need to check some concept at wikipedia. If you suddenly notice that you don't understand something, go back to where you lost it, and start working again. Always have a pen and pencil, and do notes, while reading. Also, coming up with your own memorization rules will probably help a lot. Spatial, graphic, really silly poems... what ever seems to work best for you, you'll have to discover yourself. Some stuff you come across, cannot really be deduced except through some really loong proof that you are going to forget anyway. Do the proof once, so you see what's happening, and then accept the truth of it and use the memorized end result.
There's probably some point beyond which it's really difficult to increase your math skills but it's likely waaay ahead.
> Do you think that computer technicians can make a difference in the adoption of OSS? And if they're for OSS, should they try to put some pressure on their users/clients? If price of a software product is not the problem, I'd say that the responsibility of a computer technician, as an engineer, would be to suggest, if he was questioned, to find the most cost effective solution to a particular task. Including the number of hours it would take work time for the new user to learn to use the software. Really, your main concern should be the productivity of the software and the maintainability. The cost of the software to an organization usually is neglible compared to the labor costs. Sometimes free options are just fine and dandy, or even better than anything else. And sometimes you just don't have anything that compares to a commercial product (say, like Adobe's CS suite , some engineering FEM modeling software like Ansys). Learn the need, then find the best tool for the job. It's all process instructions to the computer, and the value to the end user is in the final product (a publication, report, memo, whatever), not the tool he used.
Well, this comment is kinda lateral (as in 'not related to opengl and games'), but I think you'd appreciate flipping through a few basic computer graphics books and related maths --- after all, opengl is just an implementation of the few of the most basic concepts and the red&blue books are mostly 'just' technical reference manuals. getting a handle of the basic concepts also probably clarifies what you actually want to do with the code.
l
...and, if you have the access then the http://portal.acm.org/ stuff is really good. (search for 'siggraph "course notes" for starters') You can find details to most of the stuff Pixar, Alias etc. do from there...
Graphics:
watt&watt: Advanced Animation and Rendering Techniques - not a very recent book but the material is still relevant and the presentation of different concepts is relly good
Hearn & Baker: Computer graphics (c or opengl version depending on your preferences). Basic computer graphics. Pretty good. The opengl version eschews some of the more basic code samples from the c version, which is a bit shame really.
Moller & Haines: Real-Time Rendering - relevant for real time applications and contains great references to computer graphics resources in general
Geometry & linear algebra:
Philip Schneider & David Eberly: geometric tools for computer graphics (contains recipes for eg. checking collisions, raytracing, clipping...). Might be not best book of this type(?) but it's ok.
Freely available online material:
comp.graphics.algorithm faq:
http://www.faqs.org/faqs/graphics/algorithms-faq/
The physical modeling course of David Baraff available online is quite nice:
http://www.cs.cmu.edu/~baraff/sigcourse/index.htm
Graphics gem's codes:
http://www.acm.org/pubs/tog/GraphicsGems/
The book's themselves are also excllent recipe repositories, but really useful only after you know the basic concepts from basic textbooks etc.
If you have the time and resouces, then the Moller & Haines book is a decent roadmap to the field ("Oh, what's this...let's see the referred book/article has to say.. oh, that's interesting!") from the grass roots of z-buffers up to modern fps engine concepts.
True. Some indicators for solar activity have been recorded for over a hundred years; the aforementioned magnetometer data and the sunspot number: http://www.ngdc.noaa.gov/stp/IONO/sunspot.html
Also, prominences located at the edges of the visible "disk" of the sun have been observed probably as long as that: I found some nice modern day examples in here: http://www.digilife.be/club/Franky.Dubois/world.ht m
But, none of these methods produce quantitative data of the precision or scope available today. One of the top instruments (well, intstrument platform actually)is the SOHO spacecraft launched in 1995 http://sohowww.nascom.nasa.gov/
There have probably been other solar observing satellites prior to soho, but I can't remember any specifics (anyone?).
So, yes, unless a particle storm from a CME event hit earth square in the face, so to speak, there would be no quantitative data of such an event older than... a handful of decades?
Yes, they did. The culprit is known as "sunspot 486". More data at www.spaceweather.com.
Is the sun's rotation much greater than 24 hours?
Actually, there's a latitudal variation to the angular speed of the sun's surface. The period of sun's rotation around solar equator is 29 (Earth)days. On the 60 latitude it's 25 days.
If, however, we do have 100+ years date on all CME events, we would be able to say that it's a statistical anomaly. I just think it's more likely that we don't understand enough about the sun's behavior to properly characerize this event.
I suppose it's an anomalous event in the scope of the recorded history of Earth's magnetic field data... True, to extend this probabilistic term to the entire lifespan and surface of the sun would be silly. But, you have to take in he human aspect of the situation; it's on of the biggest events monitored and recorded. It's a one thing to have the mathematical intuition that events of some magnitude are possible, and to actually witness one (ie. you know that it's possible to win lottery. But you don't, very often. At least I don't :) )
Also, data related to this event has been systematically accumulated for over a hundred years. Scientific measurements of Earth's magnetic field has been recorded in many observatories from the late 19th. century. Official date for the earliest data of magnetic storm is 1868.
As a primer to those unfamiliar with space weather phenomena,in short, the charged particles from the coronal mass ejection create currents in the earth's ionosphere (altitude of 100km-200km), which due to induction, disturb Earth's magnetic field.( So no outdoor solar grill-parties, I'm afraid.). These variations are used as an indicator in the measurements... the more wiggling of the magnetic needle, the more powerful the storm, so to speak. Alas, a regular compass is not precise enough to measure these variations.
Not only did the storm that hit earth yesterday create fluctuations in the field bigger than anything in 14 years (northward pointing field component variation of over 3000 nanoteslas in a span of few minutes at 60deg latitude in northern Europe), being the 15th. strongest storm in the recorded history, the same apparently happened tonight also.
So, what does it mean? Well, time-varying magnetic fields induce electric fields. Not extremly strong fields (maximum in the range of volts/km), but in long conductors even relatively weak fields can effect strong currents. 1989 most of Quebec's powergrid suffered a black-out due to these geomagnetically induced currents.
Now as it happened, the magnetic field in the yesterdays particle eruption was luckily beningly aligned- same direction as Earth's field, which deflected ... buffeted...the particles... oh, it's complicated. Anyway, if the field had been pointed antiparallel to Earth's field, the particles would have flushed in in to ionosphere creating lot more of electromagnetic activity.
Well, enough of rambles. My point was that when you analyze the this event, it's not just about some single fluctuating random variable. And it's not rare just on the scope of some obscure numerological thingamajick of a model. Actually you've got a plenty of fluctuating variables...or something. And also a beautiful display of northern lights, if you're lucky.
(Damn clouds, no aurora borealis for me.)