Comments by John B Oliver

John B Oliver 18-Aug-15 18:22pm View

Reason for my vote of 1 \n This is not an article.
There is absolutely no information about how the algorithms work.

John B Oliver 16-Feb-15 16:03pm View

Reason for my vote of 1 \n "It is best practice to use Base64String to interchange the user credentials". Ummm what? At No stage should Base64 be used for transport of user credentials.
Then you mention "so there are chances that vulnerable people can hack the username and passwords" in the Risk section. Everyone using a web site that implements Base 64 encoding of user credentials over HTTP are vulnerable - EVERYONE

Your only saving grace was the final section of you document - Risk although this should be at the very start of the article not at the end.

John B Oliver 6-Oct-14 17:45pm View

Reason for my vote of 5 \n Nice little tip.
Although, by god, those images are just insane!

John B Oliver 19-Mar-14 17:19pm View

Reason for my vote of 5 \n Just because of the awesome reference to TPB!

John B Oliver 6-Jan-14 17:06pm View

Reason for my vote of 1 \n Using multiple projects means you do not have to compile the entire code base for a single code change; rather, only those projects that are dependant upon the project being modified need to be compiled.
This can greatly decrease the time it takes to compile large solutions.

John B Oliver 16-Dec-13 20:11pm View

Reason for my vote of 1 \n a) You are proposing the use of SHA1 and MD5. These 2 algorithms are so easily cracked they should be wiped from the conscience of all developers around the world.
b) You are reinventing the wheel. Just use the .Net crypto libraries. As an added benefit, you can even use SHA512!
c) You are supposed to be a senior developer. You have been given the opportunity to change the security algorithms and didn't take it. My God!!! What were you thinking?

John B Oliver 13-Nov-13 16:59pm View

Reason for my vote of 1 \n Storing a password in plain text is incompetent in the extreme an disrespectful of the owners of the password. At No stage should an application be able to retrieve a password - if an application can do it, an attacker can do it. Password checking should be done through a one-way encryption algorithm, although simply salting a password and storing that is now no longer enough (see http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html[^]); meaning other mechanisms are now required.

Please either remove this tip or add a very big disclaimer

John B Oliver 13-Nov-13 16:57pm View

Reason for my vote of 1 \n Interesting that your comment has 3 votes and an average of 3.4! Someone obviously doesn't like your comment.
But this point cannot be stressed enough.

Storing a password in plain text is incompetent in the extreme an disrespectful of the owners of the password. At No stage should an application be able to retrieve a password - if an application can do it, an attacker can do it. Password checking should be done through a one-way encryption algorithm, although simply salting a password and storing that is now no longer enough (see http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html[^]); meaning other mechanisms are now required.

Please either remove this tip

John B Oliver 29-Oct-13 17:18pm View

Reason for my vote of 2 \n I cant believe we have another example of direct Sql execution
The only reason why I will give this a 3 is because the method works.

John B Oliver 17-Jul-13 17:52pm View

Reason for my vote of 4 \n Nice little utility script.
ut I only gave you 4 because you need to RE-FACTOR the DownloadFile() method.

John B Oliver 30-Jan-13 16:12pm View

Reason for my vote of 4 \n The only issue I have found with this is when using multiple schemas in a single database.
Otherwise, great work.

John B Oliver 13-Dec-12 15:42pm View

Reason for my vote of 1 \n This does NOT remove all but one IsNull() function. The code snippet will add an IsNull() function around every column.

John B Oliver 2-Oct-12 18:00pm View

Reason for my vote of 2
This is not a tip - this is a timing test of 2 code snippets that tests the execution of 2 different compilers using 2 different sets of code. Although the to-be-compiled code in "TestOld" is equivalent to the to-be-compiled code in "TestRoselyn", the code is, in fact, quite different. As such, it is very hard to draw any conclusions on a comparison between the Roslyn compiler and the Native compiler using the code snippets in the article.
You indicate that there may be some caching mechanism somewhere, but you fail to prove this. One way of attempting a proof would be to execute the test 100 times, taking the timings of all passes in all executions, then analysing these. If you consistently find that on the first pass there is a much larger execution cost, then you can 'assume' (and probably correctly) that the other passes are benefiting from some sort of caching.
There are also a number of passes where the execution of the Roslyn function takes far longer than other Roslyn function calls (pass 4, 20, 24) that cannot be attributed to setup costs, but you do not go into any mechanisms as to why this would be the case. Are the results for these passes consistent in producing anomolous results over many executions?

John B Oliver 22-Apr-12 18:33pm View

Reason for my vote of 5
Nice work.
More an article than a tip though. :-)

John B Oliver 20-Sep-11 17:53pm View

Deleted

Interesting, but it does mean you will have additional code in a release version of the application that needs to be executed.

John B Oliver 13-Sep-11 18:02pm View

Deleted

Reason for my vote of 5
I was just about to write up this alternative myself.

John B Oliver 27-Jun-11 18:18pm View

Deleted

Correct. ALTER statements are unable to be used to re-create a database.
With a system of over 1000 stored procedures, functions and views (not to mention indexes, foreign keys etc), the task of re-creating a database is not easy.
If your source control system only contains ALTER statements, then you have to find a way of creating the stored procedures in the first place. You could store both the ALTER and CREATE scripts, but you can guarantee there will be discrepancies between the two scripts.
This does render the [modify_date] field value redundant, but I'm happy to live with this as it doesn't really give you anything of benefit.

And all you need are 3 lines of code.
if not object_id('<owner>.<procname>', 'P') is null
drop procedure <owner>.<procname>;
go

create procedure <owner>.<procname>
...

John B Oliver 19-May-11 23:14pm View

Deleted

Or you could write a stored procedure and not only have a (or many) query plan(s) created for the stored procedure, but you also encapsulate the code.
<pre lang="sql">
if not object_id('dbo.p_GetPodByID', 'P') is null
drop procedure dbo.p_GetPodByID;
go
create procedure dbo.p_GetPodByID
(
@PodId int
)
as
begin
set nocount on;
set rowcount 0;

select id ,pcname
from pod
where id = @PodId;
end</pre>

Comments by John B Oliver (Top 18 by date)