I remember Cloudera saying that most people use hadoop for ETL. Not sure if you've checked, but hadoop is like the ne plus ultra of ETL tools. It's worth a look if you have to transform lots and lots of data.
The problem is you still have to Extract data from other systems, Transform them to make them suitable for Hadoop and Load them in HDFS (or S3). Once that data is available to Hadoop, it becomes extremely powerful.
Practically all analytical systems have the same issue. The reason to use an analytics system, like Hadoop, is because the database is not fast enough to query. I say "fast enough" because even though many databases *could* be fast enough, it become contentious to perform queries that utilize resources required in production.
I'm not holding my breath for ETL companies to arrive that make this initial process easier as each client would have different network, databases, and software that would have to be supported. A better tactic is to work towards publishing streams of data from the start and building an ETL system that can help distribute the leg work across an organization.
One thing to consider is when a refusal happens. A family member of mine was given 14 shots totalling well over 30 vaccines at the age of 2. Tragically, she has autism. While it is controversial to conclude that the vaccines caused the condition, I don't believe it is controversial to consider vaccination 14 shots at 2 years old extreme.
I agree that vaccination is a good thing, at the same time, the schedule of these vaccines should be considerate of the child's development. The same goes for categorizing what vaccinations are required. When I was kid we didn't have a chickenpox vaccine and most people my age ended up getting at some point. Refusing a child at a school because they lack a chickenpox vaccine seems silly in my eyes.
This seems like a magic version of logic programming. Rather than defining precedural instructions, you provide a set of rule that a logic engine then uses when accepting input. My understanding is this is how Prolog and Datalog work, an example being Cascalog in Clojure where you define a query and the logic engine will infer the necessary joins and such to make it happen.
Generally this model of thinking appeals to me, but in practice it is difficult to get right unless your language has explicit support for it. Functional languages with tools like pattern matching and multimethods are a great example of supporting this kind of workflow.
In some ways I can see the model handling extremely complex problems. With that said, the reactive programming model seems like it misses the advantage by simply reacting to changes in input. As others have mentioned, what happens with circular reactions or highly inefficient operations? A logical programming model allows for an engine of sorts that analyzes the "reactions" in order to find where it can be optimized as well as decide whether it is flawed.
Obviously a logical programming model is not a panacea, and I'm not an expert, but it seems a more genuine attempt at handling the sort of complexity that reactive programming aims to solve.
I've found the best way to learn a code base is to start editing it. There are almost always formatting details and names that don't feel right. Start changing those and see what happens. The process will force you to understand the logic and help you really understand the code. Even if you throw all your formatting changes away, you'll definitely learn something.
Hopefully, the project has tests as well that will let you see if your formatting changes break things, in which case you've begun to understand the relationship between different code blocks.
I've traveled 150+ dates a year while keeping a full time job and I can say that it is not easy. While most of that time is spent in a van and in nasty green rooms, there have been some helpful tricks that have helped a great deal being productive while on the road.
1. Keep whomever you work for in the loop. There are going to be times where you are missing a meeting or will have trouble being available. Most of the time isn't a big deal if you're up front an open about where you are. It also helps if you end up keeping somewhat "off hours", which I typically do.
2. Get a MiFi or some other reliable internet source. Coffee shops and hotels often have flaky connections. When you do need to have that meeting or restart some services, it is beneficial to have a connection that is reasonably reliable. Also, if you use Linux full time, a MiFi is like any other wifi, which can mean less futzing with USB drivers.
3. If you work while "moving" (ie in a van, train, plain, etc.) then make sure you don't get motion sickness. I used to take Dramamine and Bonine, but both made me extremely tired and put me in a horrible mood. Since then I keep a lot of ginger chews / gum and natural motion sickness remedies. Specifically, I use a chewable tablets with Nux Vomica and Cocculus Indicus. You can pop that stuff like candy and it really works.
4. Have different themes available for your text editor. When traveling, having a light and dark theme is helpful when you may not have the best natural lighting or you have to battle some sunshine outdoors or by a window.
5. Battery life is critical! A small power efficient laptop is really helpful, especially if you have to carry it around. I also keep a small power inverter for working in the car. You want to get the lowest power possible as they are less likely overheat and break.
I've also found that using a email client that can work offline is helpful at times. I use Emacs + Mu4e with offlineimap and have found it to be helpful at times. Org-mode in Emacs is also helpful as it provides me with a timesheet and a helpful system of organizing my notes that is close to the code. This is nice b/c when traveling, you typically will have shorter time spans to focus. Being able to clock out and keep a note of what you were working open when you close your laptop can go a long way when trying to get back to work.
One caveat I'd argue is to recognize the difference between the ability to program vs. programming in PHP. I had a terrible interview where the person chided me for not knowing a specific array function. While I'm sure he was correct that the array function was a better tool, I also got the impression he was not evaluating my skill as a programmer, but rather my knowledge of PHP.
When I would interview people I would often ask about more general web development aspects. For example, what happens to the request before you get your $_POST (or whatever language specific object)? It was always surprising to find that many people had no clue what really happened and would respond that it was irrelevant since the web framework or language takes care of everything. This is not a good answer since it doesn't reveal any understanding of HTTP as a protocol as well as reveals a lack of interest to dig deeper.
If I were to ask a developer to write a web application on the spot, I wouldn't really care about the language as much as I would ask about what the different parts of their framework/tool/library did in terms of responding to requests.
I would love to see if different code styles could be analyzed to see how many peopel use what sort of syntax style. There is camelCase and under_scores but it seems possible to find more complicated trends that might allow reviews to statistically determine what practices really help to make code better.
I know the feeling. Most jobs are posted by folks that just want the buzzwords. I have been reading about Java or.Net shops that put things like rails, python and css all on the same job description as though someone needs to know all of these things to do Java or C#. It is pretty ridiculus. I try to stick to jobs that want fast learners and who want people with real system design experience. I specifically look for mentions of some sort of development cycle (extreme programming, rup, scrum, etc.) and mention something about having a framework or specific product already. I have found there is no profitable web development company that is worth dealing with unless they have a good deal of utility code that they rely on. Good Luck!
You are correct from a statistical standpoint, but this does not mean the data is not meaningful. More specifically, by watching the video you can see trends that apply to many aspects of the desktop. The statistical side of the project is in it infancy, but the raw data is still very compelling.
If you do have suggestions on how to make better use of the raw data I would suggest sending posting on the usability list at gnome.org. There are already tools being developed to further analyze the data and find more statistically meaningful results.
doesn't mean you deserved it. With colleges forcing grad students and junior faculty to meet quotas regarding grades, an "A" is very rarely the result of your hard work in a course like technical writing. In addition, technical writing courses rarely deal with things like specs and design documents in a realistic fashion. The teachers in these kind of courses are meant to analyze very basic elements that revolve around following instructions more than writing a spec that is easy to understand and use.
I am not saying you did not deserve your grade, but I am saying that good technical writing in context is not easy.
Being in a band and having some success, I would say it is near impossible to truly do everything on your own. The problem is not that you are unable to do everything yourself. The real issue is getting credibility. Credibility can be purchased to some extent but there is always a certain amount of respect that you must have earned before you are offered the ability to purchase this kind of credibility.
The label gives you credability because they spend money on you. A publicist gives you credibility because they took you on as a client (which isn't easy!). The distributor gives you credibility because they keep 500+ of your record around waiting for the masses to buy them. The booking agent gives you credibility because of the months of time they spend talking to promoters and arranging the tours (along with the money, food, blue m&ms, etc.). The writers that take the word of the publicist that you are good gives you credibility. And the radio stations that are constantly being asked how many times you song has been played give the impression to program directors that you are important.
It is all about being given this respect and credibility from those in position to make things happen for you. If you do it all yourself, you are at a disadvantage b/c are you having to toot your own horn all the time. No one thinks I am a great hacker because I say I am. It is when Eric Raymond and Alan Cox are saying I can change the world with my code that I am respected and given opportunities. With that said, anyone can do it. If you work hard and don't mind the fact that talent is not enough, then you can do it (and have a ton of fun!).
With that said, a shameless ad for my own band is required. We have a record coming out on Pretty Activity Records (http://prettyactivity.com). Our website is http://umemusic.com (be gentle...). We are touring in late May to early June and then again in August (I have an internship with Novell/Ximian in between:). Good luck to anyone going for it. The politics have never taken away from the great experiences and people that we have met and it is all totally worth it.
The thing about XForms is that it doesn't limit itself to just browsers. Much of what the w3c does is not limited to strictly the Web Domain. While no browser supports XForms currently, there is a potential that things like xhtml and the like might be a moot point after a while. The "browser" might be a much simpler application that is more of a gateway to a real application instead of a kind of viewer. After taking a look at WHAT it seems they are looking at things from a strictly web scope. Not that this is bad, but it would be much better if instead of making better standards because of web browsers, we just had the opportunity to use our own applications as they are.
I am not really sure the need to reverse engineer virii because most are released to public already. Talented virus writers seldom release their work into the wild but rather simply create them to reveal weaknesses in software. It is then a "script kiddie" who takes the code and releases into the wild. As we all know this is often an effort to simply look cool. This being the case it might be more practical to just pay attention to security sites than to mess with virii that have already screwed people over. The paper does look interesting though.
I am still in college myself getting a second degree in Information Sciences and Technology (http://ist.psu.edu) and I have been able to find work pretty easily by simply offering to work for free. My goal is to get an internship and work for experience so I have been able to go into a job and show them my skills without them needing to worry about paying me. After proving myself, which often times has been only in the interview process, I am given a job. This summer I have been doing contract work that has been very lucrative because of this method. If you love technology you will do anything to get your foot in the door.
Slashdot Mirror
I remember Cloudera saying that most people use hadoop for ETL. Not sure if you've checked, but hadoop is like the ne plus ultra of ETL tools. It's worth a look if you have to transform lots and lots of data.
The problem is you still have to Extract data from other systems, Transform them to make them suitable for Hadoop and Load them in HDFS (or S3). Once that data is available to Hadoop, it becomes extremely powerful.
Practically all analytical systems have the same issue. The reason to use an analytics system, like Hadoop, is because the database is not fast enough to query. I say "fast enough" because even though many databases *could* be fast enough, it become contentious to perform queries that utilize resources required in production.
I'm not holding my breath for ETL companies to arrive that make this initial process easier as each client would have different network, databases, and software that would have to be supported. A better tactic is to work towards publishing streams of data from the start and building an ETL system that can help distribute the leg work across an organization.
One thing to consider is when a refusal happens. A family member of mine was given 14 shots totalling well over 30 vaccines at the age of 2. Tragically, she has autism. While it is controversial to conclude that the vaccines caused the condition, I don't believe it is controversial to consider vaccination 14 shots at 2 years old extreme.
I agree that vaccination is a good thing, at the same time, the schedule of these vaccines should be considerate of the child's development. The same goes for categorizing what vaccinations are required. When I was kid we didn't have a chickenpox vaccine and most people my age ended up getting at some point. Refusing a child at a school because they lack a chickenpox vaccine seems silly in my eyes.
This seems like a magic version of logic programming. Rather than defining precedural instructions, you provide a set of rule that a logic engine then uses when accepting input. My understanding is this is how Prolog and Datalog work, an example being Cascalog in Clojure where you define a query and the logic engine will infer the necessary joins and such to make it happen.
Generally this model of thinking appeals to me, but in practice it is difficult to get right unless your language has explicit support for it. Functional languages with tools like pattern matching and multimethods are a great example of supporting this kind of workflow.
In some ways I can see the model handling extremely complex problems. With that said, the reactive programming model seems like it misses the advantage by simply reacting to changes in input. As others have mentioned, what happens with circular reactions or highly inefficient operations? A logical programming model allows for an engine of sorts that analyzes the "reactions" in order to find where it can be optimized as well as decide whether it is flawed.
Obviously a logical programming model is not a panacea, and I'm not an expert, but it seems a more genuine attempt at handling the sort of complexity that reactive programming aims to solve.
I've found the best way to learn a code base is to start editing it. There are almost always formatting details and names that don't feel right. Start changing those and see what happens. The process will force you to understand the logic and help you really understand the code. Even if you throw all your formatting changes away, you'll definitely learn something.
Hopefully, the project has tests as well that will let you see if your formatting changes break things, in which case you've begun to understand the relationship between different code blocks.
I've traveled 150+ dates a year while keeping a full time job and I can say that it is not easy. While most of that time is spent in a van and in nasty green rooms, there have been some helpful tricks that have helped a great deal being productive while on the road.
1. Keep whomever you work for in the loop. There are going to be times where you are missing a meeting or will have trouble being available. Most of the time isn't a big deal if you're up front an open about where you are. It also helps if you end up keeping somewhat "off hours", which I typically do.
2. Get a MiFi or some other reliable internet source. Coffee shops and hotels often have flaky connections. When you do need to have that meeting or restart some services, it is beneficial to have a connection that is reasonably reliable. Also, if you use Linux full time, a MiFi is like any other wifi, which can mean less futzing with USB drivers.
3. If you work while "moving" (ie in a van, train, plain, etc.) then make sure you don't get motion sickness. I used to take Dramamine and Bonine, but both made me extremely tired and put me in a horrible mood. Since then I keep a lot of ginger chews / gum and natural motion sickness remedies. Specifically, I use a chewable tablets with Nux Vomica and Cocculus Indicus. You can pop that stuff like candy and it really works.
4. Have different themes available for your text editor. When traveling, having a light and dark theme is helpful when you may not have the best natural lighting or you have to battle some sunshine outdoors or by a window.
5. Battery life is critical! A small power efficient laptop is really helpful, especially if you have to carry it around. I also keep a small power inverter for working in the car. You want to get the lowest power possible as they are less likely overheat and break.
I've also found that using a email client that can work offline is helpful at times. I use Emacs + Mu4e with offlineimap and have found it to be helpful at times. Org-mode in Emacs is also helpful as it provides me with a timesheet and a helpful system of organizing my notes that is close to the code. This is nice b/c when traveling, you typically will have shorter time spans to focus. Being able to clock out and keep a note of what you were working open when you close your laptop can go a long way when trying to get back to work.
Good luck!
One caveat I'd argue is to recognize the difference between the ability to program vs. programming in PHP. I had a terrible interview where the person chided me for not knowing a specific array function. While I'm sure he was correct that the array function was a better tool, I also got the impression he was not evaluating my skill as a programmer, but rather my knowledge of PHP.
When I would interview people I would often ask about more general web development aspects. For example, what happens to the request before you get your $_POST (or whatever language specific object)? It was always surprising to find that many people had no clue what really happened and would respond that it was irrelevant since the web framework or language takes care of everything. This is not a good answer since it doesn't reveal any understanding of HTTP as a protocol as well as reveals a lack of interest to dig deeper.
If I were to ask a developer to write a web application on the spot, I wouldn't really care about the language as much as I would ask about what the different parts of their framework/tool/library did in terms of responding to requests.
I would love to see if different code styles could be analyzed to see how many peopel use what sort of syntax style. There is camelCase and under_scores but it seems possible to find more complicated trends that might allow reviews to statistically determine what practices really help to make code better.
I know the feeling. Most jobs are posted by folks that just want the buzzwords. I have been reading about Java or .Net shops that put things like rails, python and css all on the same job description as though someone needs to know all of these things to do Java or C#. It is pretty ridiculus. I try to stick to jobs that want fast learners and who want people with real system design experience. I specifically look for mentions of some sort of development cycle (extreme programming, rup, scrum, etc.) and mention something about having a framework or specific product already. I have found there is no profitable web development company that is worth dealing with unless they have a good deal of utility code that they rely on. Good Luck!
You are correct from a statistical standpoint, but this does not mean the data is not meaningful. More specifically, by watching the video you can see trends that apply to many aspects of the desktop. The statistical side of the project is in it infancy, but the raw data is still very compelling.
If you do have suggestions on how to make better use of the raw data I would suggest sending posting on the usability list at gnome.org. There are already tools being developed to further analyze the data and find more statistically meaningful results.
doesn't mean you deserved it. With colleges forcing grad students and junior faculty to meet quotas regarding grades, an "A" is very rarely the result of your hard work in a course like technical writing. In addition, technical writing courses rarely deal with things like specs and design documents in a realistic fashion. The teachers in these kind of courses are meant to analyze very basic elements that revolve around following instructions more than writing a spec that is easy to understand and use.
I am not saying you did not deserve your grade, but I am saying that good technical writing in context is not easy.
Being in a band and having some success, I would say it is near impossible to truly do everything on your own. The problem is not that you are unable to do everything yourself. The real issue is getting credibility. Credibility can be purchased to some extent but there is always a certain amount of respect that you must have earned before you are offered the ability to purchase this kind of credibility.
:). Good luck to anyone going for it. The politics have never taken away from the great experiences and people that we have met and it is all totally worth it.
The label gives you credability because they spend money on you. A publicist gives you credibility because they took you on as a client (which isn't easy!). The distributor gives you credibility because they keep 500+ of your record around waiting for the masses to buy them. The booking agent gives you credibility because of the months of time they spend talking to promoters and arranging the tours (along with the money, food, blue m&ms, etc.). The writers that take the word of the publicist that you are good gives you credibility. And the radio stations that are constantly being asked how many times you song has been played give the impression to program directors that you are important.
It is all about being given this respect and credibility from those in position to make things happen for you. If you do it all yourself, you are at a disadvantage b/c are you having to toot your own horn all the time. No one thinks I am a great hacker because I say I am. It is when Eric Raymond and Alan Cox are saying I can change the world with my code that I am respected and given opportunities. With that said, anyone can do it. If you work hard and don't mind the fact that talent is not enough, then you can do it (and have a ton of fun!).
With that said, a shameless ad for my own band is required. We have a record coming out on Pretty Activity Records (http://prettyactivity.com). Our website is http://umemusic.com (be gentle...). We are touring in late May to early June and then again in August (I have an internship with Novell/Ximian in between
The thing about XForms is that it doesn't limit itself to just browsers. Much of what the w3c does is not limited to strictly the Web Domain. While no browser supports XForms currently, there is a potential that things like xhtml and the like might be a moot point after a while. The "browser" might be a much simpler application that is more of a gateway to a real application instead of a kind of viewer. After taking a look at WHAT it seems they are looking at things from a strictly web scope. Not that this is bad, but it would be much better if instead of making better standards because of web browsers, we just had the opportunity to use our own applications as they are.
I am not really sure the need to reverse engineer virii because most are released to public already. Talented virus writers seldom release their work into the wild but rather simply create them to reveal weaknesses in software. It is then a "script kiddie" who takes the code and releases into the wild. As we all know this is often an effort to simply look cool. This being the case it might be more practical to just pay attention to security sites than to mess with virii that have already screwed people over. The paper does look interesting though.
I am still in college myself getting a second degree in Information Sciences and Technology (http://ist.psu.edu) and I have been able to find work pretty easily by simply offering to work for free. My goal is to get an internship and work for experience so I have been able to go into a job and show them my skills without them needing to worry about paying me. After proving myself, which often times has been only in the interview process, I am given a job. This summer I have been doing contract work that has been very lucrative because of this method. If you love technology you will do anything to get your foot in the door.